Object time series system

ABSTRACT

Methods and systems for structuring, storing and displaying time series data in a user interface. One system includes processors executing instructions to determine, from time series data from a first sensor, a first subset of time series data for the first batch from the first start time and the first end time, determine, from the time series data from the first sensor, a second subset of time series data for the second batch from the second start time and the second end time, generate a time series user interface comprising a chart, the chart including a first plot for the first subset of time series data and a second plot for the second subset of time series data, the first plot being aligned to the second plot, and cause presentation of the time series user interface.

TECHNICAL FIELD

The present disclosure relates to systems and techniques for dataintegration and analysis, which may, in some embodiments includeindexing time series sensor data for subsequent retrieval, analysis andpossibly control of one or more technical systems based on the analysis.

BACKGROUND

Sensor systems monitoring processes or operations of a system cancollect time series data, which may include numerous sensed data samplesand a corresponding time indication of when each data sample wascollected. Time series data may be related to a number ofcharacteristics and properties, for example, including temperature,pressure, pH, light, infrared (IR), ultraviolet (UV), acceleration,dissolved oxygen, optical clarity, CO², motion, rotational motion,vibration, sound, voltage, current, capacitance, electromagneticradiation, altitude, fluid flow, radiation, optical, and moisture,proximity and the like. In different contexts, the collection of thetime series data from a plurality of sensors can correspond a discretegrouping of events (or a batch) such as a trip or segment of a trip(e.g., sensors on a vehicle during a trip), a chemical reaction in aplant or factory, or a product assembly in a factory.

However, from the perspective of sensors gathering time series data,there may not be a concept of a discrete grouping of events in the timeseries data but rather a large stored data set that has the all of thetime series data from a sensor lumped together. Furthermore, the largestored data set may not contain any relational information such thatanalysis of the time series data is unwieldly. Existing user interfacesto view and compare the time series data in grouping of events (orbatches) are inadequate to manipulate the large amounts of time seriesdata that can be generated during a batch because they require extensivemanual setup and data preparation of the time series data, and are aslow and tedious process for a user, if even possible at all.

SUMMARY

Embodiments of systems and methods of a time-series interaction userinterface are disclosed herein. Time series data can be stored andindexed according to an object-orientated model in a grouping of eventsin a process or evolution, which may be referred to as a “batch.” Theobject-orientated model for each batch may include properties indicativeof a start and stop time (and/or date) of the batch, and multiple timeseries associated with each batch. For example, multiple time seriessensor data, and/or corresponding quality data and determinedinformation associated with each batch. The object-orientated model mayallow computer-implemented indexing of portions of time series sensordata for subsequent retrieval and comparison, for example by using theuser interface to display and allow user interaction with identifiedportions of time series sensor data and other corresponding information,from different batches. In some embodiments, comparison of said timeseries sensor data may be automatically performed against certainpre-conditions or rules, whether or not it is displayed in the userinterface.

In one innovation, a system includes a first non-transitory computerstorage medium configured to at least store for a plurality of batches:(i) first time series object data comprising a first start time and afirst end time for a first batch, and (ii) second time series objectdata including a second start time and a second end time for a secondbatch, a second non-transitory computer storage medium configured to atleast store computer-executable instructions, and one or more computerhardware processors in communication with the second non-transitorycomputer storage medium. The one or more computer hardware processorsare configured to execute the computer-executable instructions to atleast: determine, from time series data from a first sensor, a firstsubset of time series data for the first batch from the first start timeand the first end time, determine, from the time series data from thefirst sensor, a second subset of time series data for the second batchfrom the second start time and the second end time; generate a timeseries user interface comprising a chart, the chart comprising a firstplot for at least a portion of the first subset of time series data anda second plot for at least a portion of the second subset of time seriesdata, wherein the first plot is aligned to the second plot; and causepresentation of the time series user interface.

In some embodiments, the one or more computer hardware processors may befurther configured to execute the computer-executable instructions toidentify from the aligned first and second plots a predeterminedcondition and, responsive thereto, to issue on the time series userinterface an alert as to the state of the first sensor or a technicalsystem indicated by the time series data from the first sensor. The oneor more computer hardware processors may be further configured toexecute the computer-executable instructions to issue on a time seriesuser interface of the technical system one or more user-interactiveoptions to control the technical system based on the state of the firstsensor or a technical system indicated by the time series data from thefirst sensor, for example to pause or turn-off the first sensor or thetechnical system.

In some embodiments, the one or more computer hardware processors of thesystem are further configured to execute the computer-executableinstructions to receive and store user input plot display range data forat least one of the first plot and the second plot, and in response toreceiving the user data generate a time series user interface comprisinga chart using the stored user input plot display range data, the chartcomprising a first plot for the first subset of time series data and asecond plot for the second subset of time series data, wherein the firstplot is aligned to the second plot. The first plot and the second plotmay be temporally aligned. The temporal alignment of the first plot tothe second plot aligns the portion of the first subset of time seriesdata with the portion of the second subset of time series data in thechart in a vertical or horizontal corresponding direction such thatpoints of the first plot and the second plot along the correspondingdirection represent the same point in time relative to the start of therespective first batch and second batch. In some embodiments, thewherein the user input display range data indicates a period of time,for example, seconds, minutes, hours, days, weeks, or months. In someembodiments of the system, the first start time and first end timerepresent instances in time, the first end time being after the firststart time, and the time between the first start time and the first endtime being a first time period, the second start time and second endtime represent instances in time, the second end time being after thesecond start time, the time between the first start time and the firstend time being a second time period, and the first start time and thesecond start time are different instances in time, and the first endtime of the second end time are different instances in time.

In some embodiments of such systems, the one or more computer hardwareprocessors are further configured to execute the computer-executableinstructions to generate the time series user interface such that thefirst start time of the first subset of time series data in the firstplot and the second start time of the second subset of time series datain the second plot are graphically aligned in the chart. In someembodiments of these systems, the one or more computer hardwareprocessors further configured to execute the computer-executableinstructions to generate the time series user interface such that firstplot and the second plot are aligned, having the first subset of timeseries data in the first plot and the second subset of time series datain the second plot shown in the chart as beginning at a same relativetime. In some embodiments of these systems, the one or more computerhardware processors are further configured to execute thecomputer-executable instructions to receive and store user input plotdisplay range data for at least one of the first plot and the secondplot, and in response to receiving the user data generate a time seriesuser interface including a chart using the stored user input plotdisplay range data, the chart including a first plot of the firstportion of the first subset of time series data and a second plot of thesecond portion of the second subset of the second time series data,wherein the first plot is aligned to the second plot.

In some embodiments of such systems, the one or more computer hardwareprocessors are further configured to execute the computer-executableinstructions to determine, from time series data from a second sensor, athird subset of time series data for the first batch from the firststart time and the first end time of the first batch, determine, fromthe time series data from the second sensor, a fourth subset of timeseries data for the second batch from the second start time and thesecond end time of the second batch, and cause presentation of the timeseries user interface, where the chart further comprises a first plotfor the third subset of time series data and a second plot for thefourth subset of time series data, wherein the first plot is aligned andcomparable to the second plot. In some embodiments of these systems, theone or more computer hardware processors are further configured toexecute the computer-executable instructions to determine, from timeseries data from one or more additional sensors, a corresponding numberof one or more additional subsets of time series data for the firstbatch from the first start time and the first end time of the firstbatch, determine, from the time series data from the one or moreadditional sensors, a corresponding number of one or more additionalsubsets of time series data for the second batch from the second starttime and the second end time of the second batch, and cause presentationof the time series user interface, where the chart further comprises oneor more additional plots corresponding to the one or more additionalsubsets of time series data, wherein the one or more additional plotsare also aligned and comparable to the first plot and the second plot.

Another innovation includes a method of presenting time series data in auser interface, the method including storing first time series objectdata comprising a first start time and a first end time for a firstbatch, storing second time series object data comprising a second starttime and a second end time for a second batch, using one or morecomputer hardware processors in communication with a secondnon-transitory computer storage medium configured to at least storecomputer-executable instructions, determining, from time series datafrom a first sensor, a first subset of time series data for the firstbatch from the first start time and the first end time, determining,from the time series data from the first sensor, a second subset of timeseries data for the second batch from the second start time and thesecond end time, generating a time series user interface comprising achart, the chart comprising a first plot for at least a portion of thefirst subset of time series data and a second plot for at least aportion of the second subset of time series data, wherein the first plotis temporally aligned to the second plot, and causing presentation ofthe time series user interface. The temporal alignment of the first plotto the second plot may align the portion of the first subset of timeseries data with the portion of the second subset of time series data inthe chart in a vertical or horizontal corresponding direction such thatpoints of the first plot and the second plot along the correspondingdirection represent the same point in time relative to the start of therespective first batch and second batch.

Various embodiments of the method may include certain aspects. In oneaspect, the first time series object data includes the time series datafor the first sensor and time series data for at least one other sensorfor the first batch, and the second time series object data includes thetime series data for the second sensor and time series data for at leastone other sensor for the second batch. The method may further includereceiving and storing user input plot display range data for at leastone of the first plot and the second plot, where generating the timeseries user interface comprises, in response to receiving the user data,generating using the one or more computer hardware processors the timeseries user interface comprising the chart using the stored user inputplot display range data.

The method may further include, using the one or more computer hardwareprocessors, determining, from time series data from at least oneadditional sensor, at least a third subset of time series data for thefirst batch from the first start time and the first end time of thefirst batch, determining, from time series data from the at least oneadditional sensor, at least a fourth subset of time series data for thefirst batch from the first start time and the first end time of thefirst batch, and causing presentation of the time series user interface,where the chart further comprises additional plots corresponding to theat least one additional sensor, wherein the additional plots are alsotemporally aligned and temporally aligned to the first plot and thesecond plot.

Accordingly, in various embodiments, large amounts of data areautomatically and dynamically calculated interactively in response touser inputs, and the calculated data is efficiently and compactlypresented to a user by the system. Thus, in some embodiments, the userinterfaces described herein are more efficient as compared to previoususer interfaces in which data is not dynamically updated and compactlyand efficiently presented to the user in response to interactive inputs.

Further, as described herein, the system may be configured and/ordesigned to generate user interface data useable for rendering thevarious interactive user interfaces described. The user interface datamay be used by the system, and/or another computer system, device,and/or software program (for example, a browser program), to render theinteractive user interfaces. The interactive user interfaces may bedisplayed on, for example, electronic displays (including, for example,touch-enabled displays).

Additionally, the design of computer user interfaces that are useableand easily learned by humans is a non-trivial problem for softwaredevelopers. The various embodiments of interactive and dynamic userinterfaces of the present disclosure are the result of significantresearch, development, improvement, iteration, and testing. Thisnon-trivial development has resulted in systems, methods and/or userinterfaces described herein which may provide significant performanceand control benefits. For example, embodiments may involve indexingportions of time-series sensor data as data objects for subsequentidentification and retrieval such that two or more selected portions maybe aligned, which is useful for visualization of corresponding timeseries data to identify, for example, erroneous or surprising conditions(which may prompt further interaction through the interactive userinterface, for example to shut down or take off-line a technical systemor sensor) but, in some circumstances, may allow control of one or moretechnical system or sensors to be performed automatically. For example,user interaction with the interactive user interfaces described hereinmay provide an optimized display of time-series data and may enable auser to more quickly access, navigate, assess, and digest suchinformation than previous systems, and may guide and/or prompt users totake one or more affirmative actions to control one or more systems orsensors based on the displayed time-series data.

In some embodiments, data may be presented in graphical representations,such as visual representations, such as charts and graphs, whereappropriate, to allow the user to comfortably review the large amount ofdata and to take advantage of humans' particularly strong patternrecognition abilities related to visual stimuli. In some embodiments,the system may present aggregate quantities, such as totals, counts,averages, correlations, and other statistical information. The systemmay also utilize the information to interpolate or extrapolate, e.g.forecast, future developments.

Further, the interactive and dynamic user interfaces described hereinare enabled by innovations in efficient interactions between the userinterfaces and underlying systems and components. For example, disclosedherein are improved methods of receiving user inputs, translation anddelivery of those inputs to various system components, automatic anddynamic execution of complex processes in response to the inputdelivery, automatic interaction among various components and processesof the system, and automatic and dynamic updating of the userinterfaces.

Various embodiments of the present disclosure provide improvements tovarious technologies and technological fields. For example, as describedabove, existing data storage and processing technology (including, e.g.,in memory databases) is limited in various ways (e.g., manual datareview is slow, costly, and less detailed; data is too voluminous;etc.), and various embodiments of the disclosure provide significantimprovements over such technology. Additionally, various embodiments ofthe present disclosure are inextricably tied to computer technology. Inparticular, various embodiments rely on detection of user inputs viagraphical user interfaces, calculation of updates to displayedelectronic data based on those user inputs, automatic processing ofrelated electronic data, and presentation of the updates to displayedimages via interactive graphical user interfaces. Such features andothers (e.g., processing and analysis of large amounts of electronicdata) are intimately tied to, and enabled by, computer technology, andwould not exist except for computer technology. For example, theinteractions with displayed data described herein in reference tovarious embodiments cannot reasonably be performed by humans alone,without the computer technology upon which they are implemented.Further, the implementation of the various embodiments of the presentdisclosure via computer technology enables many of the advantagesdescribed herein, including more efficient interaction with, andpresentation of, various types of electronic data.

Additional embodiments of the disclosure are described below inreference to the appended claims, which may serve as an additionalsummary of the disclosure.

In various embodiments, systems and/or computer systems are disclosedthat comprise a computer readable storage medium having programinstructions embodied therewith, and one or more processors configuredto execute the program instructions to cause the one or more processorsto perform operations comprising one or more aspects of the above-and/or below-described embodiments (including one or more aspects of theappended claims).

In various embodiments, computer-implemented methods are disclosed inwhich, by one or more processors executing program instructions, one ormore aspects of the above- and/or below-described embodiments (includingone or more aspects of the appended claims) are implemented and/orperformed.

In various embodiments, computer program products comprising a computerreadable storage medium are disclosed, wherein the computer readablestorage medium has program instructions embodied therewith, the programinstructions executable by one or more processors to cause the one ormore processors to perform operations comprising one or more aspects ofthe above- and/or below-described embodiments (including one or moreaspects of the appended claims).

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example of a schematic of an overview ofcollecting, storing data in a data store, and displaying correspondingtime series data from multiple batches in a user interface, andillustrates one view of relationships between multiple batches run onmultiple systems, and time series data corresponding to the batches thatcan include sensor data, user input data, and information determinedfrom inputs from one or more sources.

FIG. 2 illustrates one embodiment of a database system using anontology.

FIG. 3 illustrates one embodiment of a system for creating data in adata store using a dynamic ontology.

FIG. 4 illustrates defining a dynamic ontology for use in creating datain a data store.

FIG. 5 illustrates a method of transforming data and creating the datain a database using a dynamic ontology.

FIG. 6A illustrates time relationships between time series information,batches of a process, and one or more phases that may be included ineach of the batches of a process.

FIG. 6B illustrates an example of time series information andcorresponding data objects of a data store using a dynamic ontology.

FIG. 7 illustrates a computer system with which certain methodsdiscussed herein may be implemented.

FIG. 8A is an example user interface that displays time series data fromone or more sensors collected at different times, where the time seriesdata has been temporally shifted such that it aligns with each other tobe at the same instance of a process or event.

FIG. 8B is an example user interface that displays time series data fromone or more sensors collected at different times, similar to FIG. 8A butindicating detection of a predetermined condition and issuing an alerton the user interface.

FIG. 9 is an example of a flowchart for presenting time series data in auser interface.

DETAILED DESCRIPTION Overview

Technical Problem

Sensors can collect time series data. In particular, sensor systemsmonitoring processes or operations of a system can collect time seriesdata, which may include numerous sensed data samples and a correspondingtime indication of when each data sample was collected. In differentcontexts, the collection of the time series data from sensors cancorrespond to discrete a discrete grouping of events (or batch) such asa trip or segment of a trip (e.g., sensors on a vehicle during a trip),a chemical reaction in a plant or factory, sensor data for a piece ofmachinery (e.g., industrial equipment or a home water heater), or aproduct assembly in a factory. However, from the perspective of sensorsgathering time series data, there may not be a concept of a discretegrouping of events in the time series data but rather a large data setthat has the all of the data lumped together. Existing analysis systems,control systems and user interfaces to view and compare the time seriesdata in grouping of events (or batches) are inadequate to manipulate thelarge amounts of time series data that can be generated during a batchbecause they require extensive manual setup and data preparation of thetime series data, and are a slow and tedious process for a user.However, from the perspective of sensors gathering time series data,there may not be a concept of a discrete grouping of events in the timeseries data but rather a large stored data set that has the all of thetime series data from a sensor lumped together. Furthermore, time seriesdata set can be large, unwieldy to analyze and difficult to compare,whether manually or automatically.

Solution

Time series data may be related to a series of events that occur withina time period, such as events or values obtained at successive times (ofmilliseconds, seconds, minutes, hours, etc.). Time series data may alsobe related to the number of times an event occurs during a time period(of milliseconds, seconds, minutes, hours, etc.). A time-series queryand interaction user interface that supports object-orientated timeseries. The time-series data can be stored according to anobject-orientated model in a grouping of events, such as batches. Theobject-orientated model for each batch includes properties such as astart and stop time, and multiple time series associated with eachbatch, such as multiple time series sensor data associated with eachbatch. A user can setup the object-orientated model in a user interface.The time-series query user interface can receive particular batches,such as batch identifiers, and automatically construct queries and userinterfaces for the batches using the object-orientated model. Inparticular, for a received batch identifier or grouping of batchidentifies and batch type, a data model can be retrieved that specifiesthe start and stop times for the time series and which time series(e.g., for particular sensors) should be retrieved.

The time series user interface system can then automatically indexportions of time series, construct the time series user interfacesaccording to the object-orientated model and the retrieved time seriesdata. For example, using the start and stop times for multiple timeseries for the same batch type, the system can automatically time shifteach of the respective time series so a user and/or analysis system cancompare and contrast multiple batches at the same time. This may promptthe user, and/or analysis system, based on the comparing, to control oneor more systems and/or sensors in response, for example, to identifyinga predetermined condition or state made evident by the comparison.

Terms

In order to facilitate an understanding of the systems and methodsdiscussed herein, a number of terms are defined below. The terms definedbelow, as well as other terms used herein, should be construed toinclude the provided definitions, the ordinary and customary meaning ofthe terms, and/or any other implied meaning for the respective terms.Thus, the definitions below do not limit the meaning of these terms, butonly provide exemplary definitions.

Ontology: Stored information that provides a data model for storage ofdata in one or more databases. For example, the stored data may comprisedefinitions for object types and property types for data in a database,and how objects and properties may be related.

Data Store: Any computer readable storage medium, component, and/ordevice (or collection of data storage mediums and/or devices). Examplesof data stores include, but are not limited to, optical disks (e.g.,CD-ROM, DVD-ROM, etc.), magnetic disks (e.g., hard disks, floppy disks,etc.), memory circuits (e.g., solid state drives, random-access memory(RAM), etc.), and/or the like. Another example of a data store is ahosted storage environment that includes a collection of physical datastorage devices that may be remotely accessible and may be rapidlyprovisioned as needed (commonly referred to as “cloud” storage).

Database: Any data structure (and/or combinations of multiple datastructures) for storing and/or organizing data, including, but notlimited to, relational databases (e.g., Oracle databases, PostgreSQLdatabases, etc.), non-relational databases (e.g., NoSQL databases,etc.), in-memory databases, spreadsheets, as comma separated values(CSV) files, eXtendible markup language (XML) files, TeXT (TXT) files,flat files, spreadsheet files, and/or any other widely used orproprietary format for data storage. Databases are typically stored inone or more data stores. Accordingly, each database referred to herein(e.g., in the description herein and/or the figures of the presentapplication) is to be understood as being stored in one or more datastores.

Data Object or Object: A data container for information representingspecific things in the world that have a number of definable properties.For example, a data object can represent an entity such as a batch (seebelow), a sensor, a person, a place, an organization, a marketinstrument, or other noun. A data object can represent an event or agroup of events that happens at a point in time or for a duration. Adata object can represent a document or other unstructured data sourcesuch as an e-mail message, a news report, or a written paper or article.Each data object may be associated with a unique identifier thatuniquely identifies the data object. The object's attributes (e.g.metadata about the object) may be represented in one or more properties.

Object Type: Type of a data object (e.g., Batch Type, Sensor Type,Person, Event, or Document). Object types may be defined by an ontologyand may be modified or updated to include additional object types. Anobject definition (e.g., in an ontology) may include how the object isrelated to other objects, such as being a sub-object type of anotherobject type (e.g., a particular batch type can be associated with one ormore other sensor types, or an agent may be a sub-object type of aperson object type), and the properties the object type may have.

Properties: Attributes of a data object that represent individual dataitems. At a minimum, each property of a data object has a property typeand a value or values.

Property Type: The type of data a property is, such as a string, aninteger, or a double. Property types may include complex property types,such as a series data values associated with timed ticks (e.g. a timeseries), etc.

Property Value: The value associated with a property, which is of thetype indicated in the property type associated with the property. Aproperty may have multiple values.

Link: A connection between two data objects, based on, for example, arelationship, an event, and/or matching properties. Links may bedirectional, such as one representing a payment from person A to B, orbidirectional.

Link Set: Set of multiple links that are shared between two or more dataobjects.

Batch: As used herein is a broad term that refers to something thatchanges over time. A batch generally is associated with a start time andan end time, and may be monitored over a time period to collect data,the data being associated with a time during the batch (e.g., collectedat an instance of time, or collected during a period of time during thebatch). Time series data is an example of data that may be associatedwith a batch. In one example, a batch may refer to a process where amaterial or substance is subject to one or more events (or processes)that cause one or more changes to the material or substance, forexample, a grouping of related events processes or operations maycomprise a batch. In another example, a batch may refer to theoccurrence of a certain thing, a certain event, or portion of an event,that occurs numerous times. For example, the event of a train travelingfrom Chicago to Milwaukee may be referred to as a batch, and informationthat occurs on the train relating to the train itself (e.g., mechanicalinformation), or to anything that happens on the train (e.g., passengersgetting on and off, money spent in the restaurant car, communicationsmade via the trains Wi-Fi network, etc.) can be part of the datacollected for the batch.

In another example, the instances when a submarine submerges between 33feet and 330 feet may be referred to as a batch, and during such a batchnumerous data may be collected regarding the equipment operating on thesubmarine, or information relating to integrity of the hull maybecollected. In another example, a batch may refer to a circumstance orsituation when a system, or a portion of a system, operates and ismonitored over a period of time. In another example, a car driving frompoint A to Point B, or for a certain duration of time, can be referredto as a batch. Similarly, a system operating (e.g., to heat water,refine oil, make food products, travel from point A to point B, etc.)may be referred to as a batch. In another example, the processing of amaterial (any substance, e.g., water, beer, concrete, oil, produce,paint, etc.) being operated on by a system may also be referred to as abatch. One or more sensors or processes can be used to collect dataassociated with a batch, and/or one or more users can monitor a batchand provide input to a batch.

A portion of an event or process may also be referred to batch ifinformation is collected during the event or process. For example, abatch may refer to a baseball pitch/hit event, where a movement of abaseball (e.g., position, velocity, trajectory, rotation, etc.) ismonitored as it travels from the pitcher's hand to the batter, and thenfrom the batter's bat to the outfield. A batch may also refer to aportion of the baseball pitch/hit event, for example, only the portionfrom where a bat hits the baseball and the baseball travels to theoutfield. In some cases, batch data may be collected for a baseballpitch/hit event and then later it is decided to look at a portion of thecollected data as a separate batch, for example, only the portion of themovement of the baseball after the baseball is hit by the bat. In suchcases, the pitch/hit batch can be analyzed by storing as separatemetadata the exact start and end times of each time during a game abaseball leaves the pitcher's hand, gets hit by the bat and travels tothe outfield during a pitch/hit event. By generating and storing saidmetadata, a search can be done on the data. For example, subsequently, asearch can be done on the pitch/hit event batch data to identify a setof start/stop times when the baseball is hit by the bat and has traveled100 feet from the batter, and those can be considered to be a set ofbatches and analyzed.

In some embodiments, a user can also monitor a batch and characterizethe batch at one or more time instances over a period of time, e.g.,characterize the quality of the batch, or how well the batch isoperating. In some embodiments, additional information relating to thebatch may be determined. For example, determined information may begenerated by a combination of data from two or more sensors, or bytaking a sample of a substance that is associated with the batch andperforming quality analysis of the substance. In another example,determined information may be generated by a combination of data fromone or more sensors and user input (e.g., a user input characterizingquality). A batch may be represented as a data object, or as acollection of data objects, where characteristics of the batch, (e.g.,identification, start time, end time, time series data collected by eachsensor, and the like) may be represented as a data object.

Event: An occurrence that takes place over a time period, where timeseries data can be collected during the occurrence. An event may have astart time and/or an end time, or at least an indicated (or identified)start time and/or end time. An event generally occurs at a location. Forsome events, the location may cover a large geographic area. Forexample, an earthquake, ocean tides, and a space station falling out oforbit are examples of events that may occur across a large geographicarea, and including above and below the earth's surface. For some otherevents, the location may be at a specific place, for example, a factory,an office, a home, outside or at a business. For example, baking a cake,the operation of an autonomous vehicle on a route, the actuation of avalve in a cooling system, heating liquid in a container, a cuttingoperation on a piece of industrial equipment, a particular operation ofa system (or machinery) in a facility, a lap of a motorcycle around arace track, and a homerun are examples of events that occur that canoccur at a specific place. An event may be characterized by two or moreportions that may be referred to as sub-events or phases of the event.In some examples, a batch may undergo a change during one or moreevents.

Time Series Data: A series of information referenced to time. Forexample, a series of information that is sensed, collected, determined,and/or stored over a period of time, such that the information may bereferenced by the time that it was sensed, collected, determined, and/orstored. As used herein in reference to time series data, “information”is a broad term that may include sensor information and/or other typesinformation that is collected either in reference to an instance of timeor during a defined time period (e.g., milliseconds, seconds, minutes,hours, days, weeks, months, years, etc.). Time series data can includethe number of times an event occurs during a time period. Some examplesof time series data are provided here, but these examples are not meantto limit the type of information that can be included in time seriesdata. In some examples, time series of information may be generated by asensor monitoring a characteristic, for example, temperature, pressure,pH, light or radiation, dissolved oxygen, carbon dioxide, gascomposition, size, vibration, or movement. In some examples, time seriesdata may be a count of a certain occurrence over a designated period oftime, e.g., the number of people that pass through a turnstile everyminute during a week; the number of cars that travel past a certainlocation in a city every five minutes for a year; the count of telephonecalls a call center during consecutive 15 minute periods for a year; andthe amount of money all the cash registers of a store collect during 30minute time periods for a year; or the number of times a certaincomputer operation occurs (e.g., an error log or message is generated, aquery is made, a certain communication is made) in a certain timeperiod. In some examples, the series of information is determined byusing data from one sensor and other information, for example, data fromanother sensor or stored data. In another example the series informationis determined by a user's input, for example, where the user input is aquality characterization.

Object-Centric Data Model

FIG. 1 is a schematic showing an example of collecting, storing data,and displaying time series data corresponding to multiple batches in auser interface, such that the time series data of each batch is alignedto have the same relative start time. The example batches described inreference to FIG. 1 may be anything that changes and that can bemonitored over time. While the embodiments of interfaces and operationsdisclosed in reference to FIG. 1 and the other figures may illustrate orrefer to certain examples of batches, the disclosure is not limited tosuch illustrated examples but instead relates to any of the types ofbatches, as defined and described herein. Batches 105 are monitored overtime by system 100. Several types of information are collected as thebatches are subject to one or more various events or conditions that mayaffect or change the batches 105. Time series sensor information 110 iscollected by one or more sensors monitoring the batches. The time seriesinformation 110 can include sensed data for each sensor monitoring thebatches 105, and time data that corresponds to the sensed data. Forexample, for every sensed data sample collected by each sensor,corresponding time information for the sensed data sample is alsocollected. The time information may include the date when the senseddata sample was collected and the time the sensed data sample wascollected. In some examples, the time information is a timestamp thatrepresents the hour, minute, seconds, and fractions of a second, whenthe sensed data sample was collected.

FIG. 1 also illustrates time series user quality information 120 that isassociated with the batches 105. The time series user qualityinformation 120 may include time referenced input that a user makesrelating to a condition of a batch. For example a user may make a visualobservation of a batch and enter that data at the time the observationwas made. In another example where the batch is a material, a user maydraw a sample of a batch and perform one or more tests or processes onthe sample to characterize a quality of the batch. Such qualitycharacteristics may, include but is not limited to, a user observationbased on a user's vision, hearing, smell, taste, or touch. In someinstances, the quality information is based on the user's experience.

Also, in some examples, time series determined information 115 relatingto a batch may also be generated. The time series determined information115 includes a time reference indicating when the determined informationwas generated, and the determined information itself, which may be basedon two or more sources including, for example, time series sensorinformation of one or more sensors and/or time series user qualityinformation. In some examples sensor information from one or moresensors is used with a predetermined algorithm to generate the timeseries determined information. In some examples, the time seriesdetermined information 115 is generated using one or more sensors andpreviously stored information, for example, information on previouslyrun batches.

Time series sensor information 110, time series determined information115, and time series user quality information 120, may be stored in astorage component 125. In some examples storage component 125 isgeographically located with the batches 105 in an information collectionsystem 100. As further illustrated in FIG. 1, storage component 125 isin communication with analysis system 130, which may be co-located withstorage component 125, or at another location. Analysis system 130 maybe coupled to a storage component 135 which can be used to store any ofthe time series information, for example, as a working copy of the timeseries information 110. Analysis system 130, may process time seriessensor information 110, time series determined information 115, and/ortime series user quality information 120 in accordance with one moredata models, defined by an ontology, for storage of data in one or moredatabases, as further described in reference to FIGS. 2-5. Storing thetime series information in a data model facilitates indexing, forexample to create an index of which data models representing which timeseries information is stored, as well as where it is stored, to enablequickly accessing the time series information for certain time periods,which accessed time series data can be aligned, and facilitatesgenerating user interfaces comprising plots of the time seriesinformation to compare information, such as sensor data, from one ormore retrieved batches and/or automatic comparison usingcomputer-analysis techniques based on the fact that the data modelsbeing compared have known data structures and are aligned in time.

FIG. 1 also illustrates that multiple batches may be on multiplesystems, and time series data corresponding to the batches that caninclude sensor data, user input data, and information determined frominputs from one or more sources. In some examples of systems monitoringbatches, multiple batches may be “run” in series on a system 155 (e.g.,one after the other) such that the same sensors that are used to monitorand collect time series data for batch 1-1 are also used to monitor andcollect time series data for batch 1-2, . . . , batch 1-n.

In other examples of systems monitoring batches, multiple batches may berun in parallel on each of multiple systems 155, 160, and 165. Multiplesensors for a first system 155 monitor and collect time series data forbatch 1-1, batch 1-2, . . . , and batch 1-n. Multiple sensors multiplesensors for a second system 160 monitor and collect time series data forbatch 2-1, batch 2-2, . . . , and batch 2-n. Multiple sensors multiplesensors for a third system 165 monitor and collect time series data forbatch N-1, batch N-2, . . . , and batch N-n.

All of the collected time sensor data that is associated with systems155, 160, and 165 can be stored in one or more databases in accordancewith one or more data models, as described in more detail in referenceto FIGS.2-6 For example, time series data may be stored in a type ofdata object in accordance with an object definition that includes howthe data is related to other objects. Data objects may be defined invarious ways depending on a particular implementation to facilitateanalyzing and comparing the generated time series data. For example,each of the batches may be stored as a data object that includes a batchidentifier, the batch start time, the batch end time, and identifiersfor one or more events that are associated with the batch. In anotherexample, each time series data stream generated by a sensor may bestored as a data object, in such a data object may include a sensoridentifier, a system identifier indicating what system the sensor isassociated with, the sensed data generated by the sensor, and timeinformation corresponding to the sensed data generated by the sensor. Inanother example, time series data that includes user indicated qualitydata may be stored as a data object that includes a batch identifier, asystem identifier, quality data, and time information corresponding tothe quality data provided by the user. In another example, time seriesdata that includes determined information may be stored as a data objectthat includes a batch identifier, system identifier, quality data, andtime information corresponding to the determined information.

Analysis system 130 may include user input devices that allow a user toidentify certain sensor information of certain batches for display incomparison on a user interface 140, for example, by event or by a timeperiod. The time references t1, t4, t7 and t10 refer to instances oftime on the same time continuum, such that t4 occurred after t1, t7occurred after t4, and t10 occurred after t7. As illustrated in FIG. 1,user interface 140 is displaying a plot of time series sensor datacorresponding to batch 1, from time t1 to time t4. User interface 140 isalso displaying a plot of time sensor data 143 corresponding to batch 2,from time t7 to time t10. In this example, time period t1 to time t4corresponds to the time of a certain event occurring for batch 1, whilethe time period from t7 to t10 may correspond to the time of the sameevent occurring for batch 2 but later in time as the starting time forthe event for batch 1 occurred at t1 and the starting time for the eventfor batch 2 occurred at t7. Because the time series data has been savedin a data model, the user interface can display the sensor data 141 forbatch 1 and the sensor data for batch 2 for the same event such that thetime series data is aligned as starting at the same (relative time) foreasier comparison. In terms of comparison, one or more predeterminedconditions may form part of the analysis system 130 enablingcomputer-implemented detection of an event, such as a fault. Forexample, if the sensor data 141 for batch 1 varies significantly (e.g.greater than a percentage difference, as specified by a user, or bydefault) from the sensor data 143 for batch 2, at a corresponding time,then this may be flagged as a fault rather than something more benign. Aprompt may be issued to the user interface 140 to inform the user as tothe fault, or in some embodiments, the prompt may give the user theoption of controlling the associated system or sensor(s) in some way,for example to shut them down or to schedule maintenance. In someembodiments, a variation between time-aligned sensor data 141, 143 maybe compared with historical patterns of variation to identify one ormore known fault conditions, which may be provided on the user interface140.

In an implementation, the system 100 (or one or more aspects of thesystem 100) may comprise, or be implemented in, a “virtual computingenvironment”. As used herein, the term “virtual computing environment”should be construed broadly to include, for example, computer readableprogram instructions executed by one or more processors (e.g., asdescribed in the example of FIG. 7) to implement one or more aspects ofthe modules and/or functionality described herein. Further, in thisimplementation, one or more components of the system 100 may beunderstood as comprising one or more rules engines of the virtualcomputing environment that, in response to inputs received by thevirtual computing environment, execute program instructions to modifyoperation of the virtual computing environment. For example, a requestreceived from the user computing device may be understood as modifyingoperation of the virtual computing environment to cause the requestaccess to a resource from the system 100. Such functionality maycomprise a modification of the operation of the virtual computingenvironment in response to inputs and according to various rules. Otherfunctionality implemented by the virtual computing environment (asdescribed throughout this disclosure) may further comprise modificationsof the operation of the virtual computing environment, for example, theoperation of the virtual computing environment may change depending onthe information gathered by the system 100. Initial operation of thevirtual computing environment may be understood as an establishment ofthe virtual computing environment. In some implementations the virtualcomputing environment may comprise one or more virtual machines,containers, and/or other types of emulations of computing systems orenvironments. In some implementations the virtual computing environmentmay comprise a hosted computing environment that includes a collectionof physical computing resources that may be remotely accessible and maybe rapidly provisioned as needed (commonly referred to as “cloud”computing environment).

Implementing one or more aspects of the system 100 as a virtualcomputing environment may advantageously enable executing differentaspects or modules of the system on different computing devices or thesystem 100 as a virtual computing environment may further advantageouslyenable sandboxing various aspects, data, or modules of the system fromone another, which may increase security of the system by preventing,e.g., malicious intrusion into the system from spreading. Implementingone or more aspects of the system 100 as a virtual computing environmentmay further advantageously enable parallel execution of various aspectsor modules of the system, which may increase the scalability of thesystem. Implementing one or more aspects of the data the system 100 as avirtual computing environment may further advantageously enable rapidprovisioning (or de-provisioning) of computing resources to the system,which may increase scalability of the system by, e.g., expandingcomputing resources available to the system or duplicating operation ofthe system on multiple computing resources. For example, the system maybe used by thousands, hundreds of thousands, or even millions of userssimultaneously, and many megabytes, gigabytes, or terabytes (or more) ofdata may be transferred or processed by the system, and scalability ofthe system may enable such operation in an efficient and/oruninterrupted manner.

FIG. 2 illustrates one embodiment of a database system using anontology. An ontology may provide a data model for storage of timeseries data and information, for example, as described in reference toFIGS. 1, 2, and 8-10. To provide a framework for the discussion ofspecific systems and methods described herein, an example databasesystem 210 using an ontology 205 will now be described in reference toFIG. 2. This description is provided for the purpose of providing anexample and is not intended to limit the techniques to the example datamodel, the example database system, or the example database system's useof an ontology to represent information.

In one embodiment, a body of data is conceptually structured accordingto an object-centric data model represented by ontology 205. Theconceptual data model is independent of any particular database used fordurably storing one or more database(s) 209 based on the ontology 205.For example, each object of the conceptual data model may correspond toone or more rows in a relational database or an entry in LightweightDirectory Access Protocol (LDAP) database, or any combination of one ormore databases.

FIG. 2 also illustrates an object-centric conceptual data modelaccording to an embodiment. An ontology 205, as noted above, may includestored information providing a data model for storage of data in thedatabase 209. The ontology 205 may be defined by one or more objecttypes, which may each be associated with one or more property types. Atthe highest level of abstraction, data object 201 is a container forinformation representing things in the world. For example, data object201 can represent an entity such as a person, a place, an organization,a market instrument, or other noun. Data object 201 can represent anevent that happens at a point in time or for a duration. Data object 201can represent a document or other unstructured data source such as ane-mail message, a news report, or a written paper or article. Each dataobject 201 is associated with a unique identifier that uniquelyidentifies the data object within the database system.

Different types of data objects may have different property types. Forexample, a “Person” data object might have an “Eye Color” property typeand an “Event” data object might have a “Date” property type. Eachproperty 203 as represented by data in the database system 210 may havea property type defined by the ontology 205 used by the database 209.

Objects may be instantiated in the database 209 in accordance with thecorresponding object definition for the particular object in theontology 205. For example, a specific monetary payment (e.g., an objectof type “event”) of US$30.00 (e.g., a property of type “currency”)taking place on 3/27/2009 (e.g., a property of type “date”) may bestored in the database 209 as an event object with associated currencyand date properties as defined by the ontology 205. In another exampleof an event object, a batch (e.g., an object of type “batch”) in aprocess step or location in the process (e.g., a property of type“event”) starting on 3/27/2009 (e.g., a property of type “date”) at0805:00 (e.g., a property of type “start time”) and completing on3/27/2009 (e.g., a property of type “date”) at 1515:15 (e.g., a propertyof type “time”) on (or monitored by) system 1 (e.g., a property type of“system”). In another example, a specific sensor (e.g., an object oftype “sensor”) used in a system (e.g., a property of type “system”) cancollect time series data (e.g., a property of type “data”) along withtimes associated with the data (e.g., a property of type “time”). Thedata objects defined in the ontology 205 may support propertymultiplicity. In particular, a data object 201 may be allowed to havemore than one property 203 of the same property type. For example, a“Person” data object might have multiple “Address” properties ormultiple “Name” properties. In another example, a batch in a process runmay have multiple “sensor” properties indicating that multiple sensorscollected monitored the batch to collect time series data.

Each link 202 represents a connection between two data objects 201. Inone embodiment, the connection is either through a relationship, anevent, or through matching properties. A relationship connection may beasymmetrical or symmetrical. For example, “Person” data object A may beconnected to “Person” data object B by a “Child Of” relationship (where“Person” data object B has an asymmetric “Parent Of” relationship to“Person” data object A), a “Kin Of” symmetric relationship to “Person”data object C, and an asymmetric “Member Of” relationship to“Organization” data object X. The type of relationship between two dataobjects may vary depending on the types of the data objects. Forexample, “Person” data object A may have an “Appears In” relationshipwith “Document” data object Y or have a “Participate In” relationshipwith “Event” data object E. In one embodiment, when two data objects areconnected by an event, they may also be connected by relationships, inwhich each data object has a specific relationship to the event, suchas, for example, an “Appears In” relationship.

As an example of a matching properties connection, two “Person” dataobjects representing a brother and a sister, may both have an “Address”property that indicates where they live. If the brother and the sisterlive in the same home, then their “Address” properties likely containsimilar, if not identical property values. In another example, two“Batch” data objects representing two batches that were monitored by thesame system may both have a “Sensor” property that indicates the sensorthat was used to monitor each of the batches. If both batches weremonitored by the same system (e.g., at different times), then bothbatches may have one or more “Sensor” properties that are likelysimilar, if not identical, indicating one or more of the same sensorswere used to collect time series data for each of the batches. In oneembodiment, a link between two data objects may be established based onsimilar or matching properties (e.g., property types and/or propertyvalues) of the data objects. These are just some examples of the typesof connections that may be represented by a link and other types ofconnections may be represented; embodiments are not limited to anyparticular types of connections between data objects. For example, adocument might contain references to two different objects. For example,a document may contain a reference to a payment (one object), and aperson (a second object). A link between these two objects may representa connection between these two entities through their co-occurrencewithin the same document.

Each data object 201 can have multiple links with another data object201 to form a link set 204. For example, two “Person” data objectsrepresenting a husband and a wife could be linked through a “Spouse Of”relationship, a matching “Address” property, and one or more matching“Event” properties (e.g., a wedding). Each link 202 as represented bydata in a database may have a link type defined by the database ontologyused by the database.

FIG. 3 is a block diagram illustrating exemplary components and datathat may be used in identifying and storing data according to anontology. In this example, the ontology may be configured, and data inthe data model populated, by a system of parsers and ontologyconfiguration tools. In the embodiment of FIG. 3, input data 300 isprovided to parser 302. The input data may comprise data from one ormore sources. For example, an institution may have one or more databaseswith information on credit card transactions, rental cars, and people.The databases may contain a variety of related information andattributes about each type of data, such as a “date” for a credit cardtransaction, an address for a person, and a date for when a rental caris rented. In another example, a system performing a process may be incommunication with one or more databases with information about sensorsthat monitor the process and phases of the process. The databases maycontain a variety of related information and attributes of each type ofdata, for example, related to multiple sensors that collect data duringthe process, phases of the process, data sensed by a sensor, time stampsof sensor data, and corresponding information related to the process orparticular phases of the process. The parser 302 is able to read avariety of source input data types and determine which type of data itis reading.

In accordance with the discussion above, the example ontology 205comprises stored information providing the data model of data forstorage of data in database 209. The ontology 205 stored informationprovides a data model having one or more object types 310, one or moreproperty types 316, and one or more link types 330. Based on informationdetermined by the parser 302 or other mapping of source inputinformation to object type, one or more data objects 201 may beinstantiated in the database 209 based on respective determined objecttypes 310, and each of the objects 201 has one or more properties 203that are instantiated based on property types 316. Two data objects 201may be connected by one or more links 202 that may be instantiated basedon link types 330. The property types 316 each may comprise one or moredata types 318, such as a string, number, etc. Property types 316 may beinstantiated based on a base property type 320. For example, a baseproperty type 320 may be “Locations” and a property type 316 may be“Home.”

In an embodiment, a user of the system uses an object type editor 324 tocreate and/or modify the object types 310 and define attributes of theobject types. In an embodiment, a user of the system uses a propertytype editor 326 to create and/or modify the property types 316 anddefine attributes of the property types. In an embodiment, a user of thesystem uses link type editor 328 to create the link types 330.Alternatively, other programs, processes, or programmatic controls maybe used to create link types and property types and define attributes,and using editors is not required.

In an embodiment, creating a property type 316 using the property typeeditor 426 involves defining at least one parser definition using aparser editor 322. A parser definition comprises metadata that informsparser 302 how to parse input data 300 to determine whether values inthe input data can be assigned to the property type 316 that isassociated with the parser definition. In an embodiment, each parserdefinition may comprise a regular expression parser 304A or a codemodule parser 304B. In other embodiments, other kinds of parserdefinitions may be provided using scripts or other programmaticelements. Once defined, both a regular expression parser 304A and a codemodule parser 304B can provide input to parser 302 to control parsing ofinput data 300.

Using the data types defined in the ontology, input data 300 may beparsed by the parser 302 determine which object type 310 should receivedata from a record created from the input data, and which property types316 should be assigned to data from individual field values in the inputdata. Based on the object-property mapping 301, the parser 302 selectsone of the parser definitions that is associated with a property type inthe input data. The parser parses an input data field using the selectedparser definition, resulting in creating new or modified data 303. Thenew or modified data 303 is added to the database 209 according toontology 205 by storing values of the new or modified data in a propertyof the specified property type. As a result, input data 300 havingvarying format or syntax can be created in database 209. The ontology205 may be modified at any time using object type editor 324, propertytype editor 326, and link type editor 328, or under program controlwithout human use of an editor. Parser editor 322 enables creatingmultiple parser definitions that can successfully parse input data 300having varying format or syntax and determine which property typesshould be used to transform input data 300 into new or modified inputdata 303.

A user interface may show relationships between data objects.Relationships between data objects may be stored as links, or in someembodiments, as properties, where a relationship may be detected betweenthe properties. In some cases, as stated above, the links may bedirectional. For example, a payment link may have a direction associatedwith the payment, where one person object is a receiver of a payment,and another person object is the payer of payment.

In addition to visually showing relationships between the data objects,a user interface may allow various other manipulations. For example, theobjects within a database 209 may be searched using a search interface(e.g., text string matching of object properties), inspected (e.g.,properties and associated data viewed), filtered (e.g., narrowing theuniverse of objects into sets and subsets by properties orrelationships), and statistically aggregated (e.g., numericallysummarized based on summarization criteria), among other operations andvisualizations. For example, by performing one or more filtering and/oraggregation functions on the time series data represented by theobjects, some sort of time-varying baseline may be generated, indicativeof expected data with respect to time, from which erroneous data can bedetected either manually or automatically, for example with respect to apredetermined or default outlier conditions.

Advantageously, the present disclosure allows time series sensor data tobe indexed in a more useful way (as data objects with start and endtimes) to permit meaningful alignment, for users to interact and analyzeelectronic data in a more analytically useful way and/or for computationanalysis to be performed in a more useful way, for example to detectconditions requiring attention. Graphical user interfaces allow the userto visualize otherwise difficult to define relationships and patternsbetween different data objects. In the example of a system performing aprocess numerous times and being in communication with one or moredatabases with information about sensors that monitor the process andphases of the process, a graphical user interface can display timeseries sensor data of one or more sensors for corresponding times inselected processes at selected times to compare the sensor data fromprocess to process. That is, the time series sensor data for two or moreprocesses can be computer-analyzed and/or displayed in a plot in arelative time scale such that the data at the beginning of each plot isaligned to be at the same point in the process to help manually and/orautomatically identify differences in the processes. Such time seriessensor data has been parsed and stored in one or more data objects withproperties and relationships as defined by an ontology. This allows auser, through the user interface, to quickly and easily select fordisplay in one or more plots aligned time series sensor data of certainsensors, processes (or batches), systems etc., and at a desiredscale/time period of the displayed. The present disclosure allows foreasier comparison of time series data that was generated at times,and/or in different systems. The present disclosure also allows fasteranalysis of time series data by allowing quick and accurate access toselected portions of time series sensor data which may have beencollected by different sensors in different systems, or the same sensorsof the same system but during different processes of a repetitively runprocess. Without using the present disclosure, quickly selecting,displaying, and analyzing time series data, and making use of knownrelationships associated with time series data, would be virtuallyimpossible given the size and diversity of many users' presentdatabases, (e.g. excel spreadsheets, emails, and word documents).

FIG. 4 illustrates defining a dynamic ontology for use in creating datain a database. For purposes of disclosing a clear example, operationsthat may be used to define a dynamic ontology are illustrated in blocks402-409 of FIG. 4, and are first described at a high level, and detailsof an example implementation follow the high level description. Althoughthe operations may be referred to herein as “steps,” (e.g., steps 402,404, 406, etc.), unless indicated otherwise, these operations may beperformed multiple time, for example, as loops as illustrated in FIG. 4.Also, in an embodiment, these operations may be performed in a differentorder, and/or there may be fewer operations or less operations.

In step 402, one or more object types are created for a databaseontology. In step 406, one or more property types are created for eachobject type. As indicated in step 404, the attributes of object types orproperty types of the ontology may be edited or modified at any time.

In step 408, at least one parser definition is created for each propertytype. At step 409, attributes of a parser definition may be edited ormodified at any time.

In an embodiment, each property type is declared to be representative ofone or more object types. A property type is representative of an objecttype when the property type is intuitively associated with the objecttype. For example, a property type of “Social Security Number” may berepresentative of an object type “Person” but not representative of anobject type “Business.”

In an embodiment, each property type has one or more components and abase type. In an embodiment, a property type may comprise a string, adate, a number, or a composite type consisting of two or more string,date, or number elements. Thus, property types are extensible and canrepresent complex data structures. Further, a parser definition canreference a component of a complex property type as a unit or token.

An example of a property having multiple components is a Name propertyhaving a Last Name component and a First Name component. An example ofraw input data is “Smith, Jane”. An example parser definition specifiesan association of input data to object property components as follows:{LAST_NAME}, {FIRST_NAME_}→Name:Last, Name:First. In an embodiment, theassociation {LAST_NAME}, {FIRST_NAME} is defined in a parser definitionusing regular expression symbology. The association {LAST_NAME},{FIRST_NAME} indicates that a last name string followed by a first namestring comprises valid input data for a property of type Name. Incontrast, input data of “Smith Jane” would not be valid for thespecified parser definition, but a user could create a second parserdefinition that does match input data of “Smith Jane”. The definitionName:Last, Name:First specifies that matching input data values map tocomponents named “Last” and “First” of the Name property.

As a result, parsing the input data using the parser definition resultsin assigning the value “Smith” to the Name:Last component of the Nameproperty, and the value “Jane” to the Name:First component of the Nameproperty.

In an embodiment, administrative users use an administrative editor tocreate or edit object types and property types. In an embodiment, usersuse the administrative editor to specify parser definitions and toassociate regular expressions, code modules or scripts with the parserdefinitions. In the administrative editor, a user can specify attributesand components of a property type. For example, in one embodiment a userspecifies a graphical user interface icon that is associated with theproperty type and displayed in a user interface for selecting theproperty type. The user further specifies a parser definition that isassociated with the property type and that can parse input data and mapthe input data to properties corresponding to the property type. Theuser further specifies a display format for the property type indicatinghow users will see properties of that property type.

In an embodiment, an object type editor panel could comprise graphicalbuttons for selecting add, delete, and edit functions, and one or morerows that identify object types and a summary of selected attributes ofthe object types. Example selected attributes that can be displayed inobject editor panel include an object type name (e.g., Business, Asset,etc.), a uniform resource identifier (URI) specifying a location ofinformation defining the object type (for example, “com.business_entity_name.object.business”), and a base type of the objecttype, also expressed in URI format (for example, “com.business_entity_name.object.entity”). Each URI also may include agraphical icon.

In an embodiment, a user interacts with a computer to perform thefollowing steps to define an object type. Assume for purposes of anexample that the new object type is Batch. Using the object type editor,the user selects the “Add Object Type” button and the computer generatesand displays a panel that prompts the user to enter values for a newobject type. The user selects a base object type of Entity, which maycomprise any person, place or thing. The user assigns a graphical iconto the Batch object type. The user assigns a display name of “Batch” tothe object type.

In an embodiment, a user interacts with the computer to define aproperty type in a similar manner. For example, the user specifies aname for the property type, a display name, and an icon. The user mayspecify one or more validators for a property type. Each validator maycomprise a regular expression that input data modified by a parser mustmatch to constitute valid data for that property type. In an embodiment,each validator is applied to input data before a process can store themodified input data in an object property of the associated propertytype. Validators are applied after parsing and before input data isallowed to be stored in an object property.

In various embodiments, validators may comprise regular expressions, aset of fixed values, or a code module. For example, a property type thatis a number may have a validator comprising a regular expression thatmatches digits 0 to 9. As another example, a property type that is a USstate may have a validator that comprises the set {AK, AL, CA . . . VA}of valid two-letter postal abbreviations for states. Validator sets maybe extendible to allow a user to add further values. A property type mayhave component elements, and each component element may have a differentvalidator. For example, a property type of “Address” may comprise ascomponents “City”, “State”, and “ZIP”, each of which may have adifferent validator.

In an embodiment, defining a property type includes identifying one ormore associated words for the property type. The associated wordssupport search functions in large database systems. For example, aproperty type of “Address” may have an associated word of “home” so thata search in the system for “home” properties will yield “Address” as oneresult.

In an embodiment, defining a property type includes identifying adisplay formatter for the property type. A display formatter specifieshow to print or display a property type value.

In an embodiment, the parser definitions each include a regularexpression that matches valid input, and the parser uses a regularexpression processing module. For example, conventional Java languageprocessors typically have regular expression processing modules builtin. In an embodiment, parser definitions comprising regular expressionsmay be chained together. In another embodiment, one or more of theparser definitions each include a code module that contains logic forparsing input data and determining whether the input data matches aspecified syntax or data model. The code module may be written in Java,JavaScript, or any other suitable source language.

In an embodiment, there may be any number of parser definitions andsub-definitions. The number of parser definitions is unimportant becausethe input data is applied successively to each parser definition until amatch occurs. When a match occurs, the input data is mapped using theparser sub definitions to one or more components of an instance of anobject property. As a result, input data can vary syntactically from adesired syntax but correct data values are mapped into correct objectproperty values in a database.

Accordingly, referring again to FIG. 4, creating a parser definition fora property type at step 408 may comprise selecting a parser type such asa regular expression, code module, or other parser type. When the parsertype is “code module,” then a user specifies the name of a particularcode module, script, or other functional element that can performparsing for the associated property type.

In an embodiment, defining a property type includes creating adefinition of a parser for the property type using a parser editor. Inan embodiment, a screen display comprises a Parser Type combo box thatcan receive a user selection of a parser type, such as “RegularExpression” or “Code Module.” A screen display may further comprises aName text entry box that can receive a user-specified name for theparser definition.

When the parser type is “regular expression,” steps 414-420 areperformed. At step 414, regular expression text is specified. Forexample, when the Parser Type value of combo box is “RegularExpression,” a screen display comprises an Expression Pattern text boxthat can receive a user entry of regular expression pattern text.

In step 416, a property type component and a matching sub-definition ofregular expression text is specified. For example, a screen displayfurther comprises one or more property type component mappings. Eachproperty type component mapping associates a sub-definition of theregular expression pattern text with the property type component that isshown in a combo box. A user specifies a property type component byselecting a property type component using a combo box for an associatedsub-definition. As shown in step 518, specifying a property typecomponent and sub-definition of regular expression text may be repeatedfor all other property type components of a particular property type.

In step 420, a user may specify one or more constraints, default values,and/or other attributes of a parser definition. The user also mayspecify that a match to a particular property type component is notrequired by checking a “Not Required” check box. A screen display mayfurther comprise a Default Value text box that can receive user inputfor a default value for the property type component. If a Default Valueis specified, then the associated property type receives that value ifno match occurs for associated grouping of the regular expression. Inalternative embodiments, other constraints may be specified.

At step 422, the parser definition is stored in association with aproperty type. For example, selecting the SAVE button causes storing aparser definition based on the values entered in screen display. Parserdefinitions may be stored in database 209.

The approach of FIG. 4 may be implemented using other mechanisms forcreating and specifying the values and elements identified in FIG. 4,and a particular GUI of is not required.

Advantageously, use of a dynamic ontology may allow a user to takeadvantage of an ontological data model, while not constraining himselfor herself to a hard-coded ontology. Hard-coded ontologies can be overlysimple (i.e., lacking detailed semantic properties, makingclassification difficult but limiting analysis) or overly complex (i.e.,having overly detailed semantic properties, making classificationdifficult). Use of a dynamic ontology can allow a user to define thedesired level of semantic granularity, making dynamic ontologiessuitable for a plurality of different and diverse uses (e.g., fraudprevention, cyber security, governmental applications, capital markets,etc.).

Advantageously, use of a parser or other ontology configuration toolsmay allow greater scalability of a user's database without loss of anyanalytic ability. Use of a parser or other ontology configuration toolsand parser definitions, (e.g., first name, last name, etc.), may allowfor self-categorization without the need for manual coding. Manualcoding of a data object's properties may be subject to many of thedisadvantages associated with manual data entry (e.g., slow, inaccurate,and costly). Additionally, manual coding of a data object's propertiesmay not allow for dynamic ontology reconfiguration if a user chose toadjust the granularity, (i.e., specificity), or an ontologies semanticproperties.

FIG. 5 illustrates a method of transforming data and creating the datain a database using a dynamic ontology. For purposes of illustrating aclear example, the approach of FIG. 5 is described herein with referenceto FIG. 3. However, the approach of FIG. 5 may be implemented usingother mechanisms for performing the functional steps of FIG. 5, and theparticular system of FIG. 3 is not required.

In step 502, input data is received. In an embodiment, an input datafile is received. The input data file may comprise a comma-separatedvalue (CSV) file, a spreadsheet, XML or other input data file format.Input data 300 of FIG. 3 may represent such file formats or any otherform of input data.

In step 504, an object type associated with input data rows of the inputdata is identified, and one or more property types associated with inputdata fields of the input data are identified. For example, theobject-property mapping 301 of FIG. 3 specifies that input data 300comprises rows corresponding to object type PERSON and fieldscorresponding to property type components LAST_NAME, FIRST_NAME ofproperty type NAME. The object-property mapping 301 may be integratedinto input data 300 or may be stored as metadata in association with adata input tool.

In step 506, a row of data is read from the input data, and one or morefield values are identified based on delimiters or other fieldidentifiers in the input data.

In step 508, a set of parser definitions associated with the propertytype of a particular input data field is selected. For example, metadatastored as part of creating a property type specifies a set of parserdefinitions, as previously described.

In step 510, the next parser definition is applied to an input datafield value. Thus, data fields are read from each row of the file andmatched to each parser that has been defined for the correspondingproperty types. For example, assume that the mapping indicates that aninput data CSV file comprises (Last Name, First Name) values for Nameproperties of Person objects. Data fields are read from the input dataCSV file and compared to each of the parsers that has been defined forthe Name property type given the First Name field and Last Name field.If a match occurs for a (Last Name, First Name) pair value to any of theparsers for the Name property type, then the parser transforms the inputdata pair of (Last Name, First Name) into modified input data to bestored in an instantiation of a Name property.

If applying a definition at step 510 results in a match to the inputdata, as tested at step 512, then at step 518 a property instance iscreated, and the input data field value is stored in a property of theproperty type associated with the matching sub-definition of the parserdefinition. For example, assume that the input data matches the regularexpression for an ADDRESS value. The mapping specifies how to store thedata matching each grouping of the regular expression into a componentof the ADDRESS property. In response, an instance of an ADDRESS propertyis created in computer memory and the matching modified input data valueis stored in each component of the property instance.

If no match occurs at step 512, then control transfers to step 514 totest whether other parser definitions match the same input data value.As an example, a property editing wizard in which multiple parsers havebeen created for a particular property, and through the loop shown inFIG. 5, each of the multiple parsers can be used in matching input data.If no match occurs to the given parser definition, then any other parserdefinitions for that property type are matched until either no matchoccurs, or no other parser definitions are available.

If a grouping is empty, then the component is filled by the defaultvalue for that component, if it exists. If no other parser definitionsare available, then control transfers from step 514 to step 516, atwhich point an error is raised or the property is discarded

At step 520, the preceding steps are repeated for all other values androws in the input data until the process has transformed all the inputdata into properties in memory.

At step 522, an object of the correct object type is instantiated. Forexample, the object-property mapping 301 may specify an object type forparticular input data, and that type of object is instantiated. Thenewly created object is associated in memory with the properties thatare already in memory. The resulting object is stored in the database instep 524.

Steps in the preceding process may be organized in a pipeline. Using theapproaches herein, a user can self-define a database ontology and useautomated, machine-based techniques to transform input data according touser-defined parsers and store the transformed data in the databaseaccording to the ontology. The approach provides efficient movement ofdata into a database according to an ontology. The input data hasimproved intelligibility after transformation because the data is storedin a canonical ontology. Further, the approach is flexible andadaptable, because the user can modify the ontology at any time and isnot tied to a fixed ontology. The user also can define multiple parsersto result in semantic matches to input data even when the syntax of theinput data is variable.

In various implementations, data objects in ontology 205 stored indatabase 209, may be stored as graphs or graph-like relationships (whichmay comprise data structures or databases), referred to collectively as“graphs.” Some examples of graphs include an undirected graph, clusters,and adjacency lists that allow storing of graphs in memory efficiently,particularly where the graphs are lightly-connected graphs or clusters(e.g. graphs or clusters wherein the number of nodes is high compared tothe number of linkages per node). Adjacency matrices may also allow formore efficient access and processing, particularly vectorized access andprocessing (e.g. using specialized hardware or processor instructionsfor matrix math), to the graph or cluster data because each matrix rowcorresponding to a node may have the same size irrespective of thenumber of linkages by node. As described here, various data items may bestored, processed, analyzed, etc. via graph-related data structures,which may provide various storage and processing efficiency advantagesdescribed. For example, advantages of graph-related data structures mayinclude: built to handle high volume, highly connected data; efficientin computing relationship queries than traditional databases, eitherusing adjacency matrices, or adjacency lists; can easily add to theexisting structure without endangering current functionality; structureand schema of a graph model can easily flex; new data types and itsrelationship; evolves in step with the rest of the application and anychanging business data requirements; can easily add weights to edges;can use optimal amount of computer memory, etc.

The nodes of a graph may represent different information or dataobjects, for example. The edges of the graph may represent relationshipsbetween the nodes. The ontology may be created or updated in variousways, including those described herein, comprising both manual andautomatic processes. In some implementations, the ontology and or dataobjects in the graph database may be created and/or interacted withvisually through various graphical user interfaces. Advantageously, thisallows the user to interact with the data objects by placing, dragging,linking and deleting visual entities on a graphical user interface. Theontology may be converted to a low-level (i.e. node list)representation.

FIG. 6A and FIG. 6B are discussed together below, and sometime referredto collectively as FIG. 6. FIG. 6A illustrates an example of aspects oftime series data and data objects that store the time series data. FIG.6B illustrates an example of time series information 600 andcorresponding examples of data objects 601 of a data store using anontology.

In this example, the time series information 600 relates to one or morebatches 105, sensor data 110 which includes data from multiple sensors,determined data (or information) 115, quality data 120, and events 653,654, 655, 656, 657, and 658. The batches 105 include a batch identifier606, a start time 607, and an end time 608. As illustrated in FIG. 6A,time series data is collected for batch 105A for a duration of time Abetween the start time 607A and the end time 608A. Similarly, timeseries data is collected for batch 105B for a duration of time B, andtime series data is collected for batch 105C for a duration of time C.The various batches 105 may be associated with (e.g., processed by) onesystem, or multiple systems. In other words, each of batches 105 may beassociated with the same system as the other batches, or the batches maybe associated with two or more different systems. The sensor data 110includes time series data collected by a plurality of sensors thatmonitor the batches 105. The sensors collecting the sensor data for eachbatch may be the same sensors or different sensors. If the batches 105are associated with multiple (different) systems, the sensor data 110represents the time series data collected by the plurality of sensors oneach of the multiple different systems.

As discussed in reference to FIG. 1, the determined data 115 is timeseries data that includes information relating to the batches 105 thatmay be determined from multiple sources are inputs. For example, thedetermined data 115 may be determined by inputs from a user and orinputs from one or more sensors, or another source of information.

Quality data 120 is information relating to a quality characteristic ofa batch that a user may input as a batch undergoes several events. Auser may determine a quality characteristic of a batch by one of theirsenses (for example, sight, sound, touch, taste, and smell). Forexample, in an embodiment of a batch where ingredients are processed toform a cake, during a mixing event (and at a certain instance in time) auser may determine a consistency quality of the mix to be thin, smoothor coarse. In a later event (and at a certain instance in time) when theingredients are being heated in an oven, a user may determine by site ortouch the quality aspect that at a certain point in time the cake hasbeen sufficiently baked. Once the cake is removed from the oven, a usermay determine, by taste, a quality aspect of how well the cake tastes ata certain instance in time. Additionally or alternatively, the qualitydata 120 can include data that is generated by a system or machine.

FIG. 6 also illustrates an example of events 650 that includes multipleevents 653, 654, . . . 658 that may occur during each of batches 105A,105B, 105n. Batch 105A has a start time of 607A and an end time of 608A.Batch 105B, as a start time of 607B and an end time of 608B. And batch105n has a start time of 607n and an end time of 608n. The events occuron a system for a specific batch, and they may occur in all similarbatches. As illustrated in FIG. 6A, batch 105A includes “Event 1” 653,“Event 2” 654, “Event X” 655, “Event 3” 656, “Event 4” 657, and “Eventn” 658. All of the events associated with a batch do not necessarilyoccur serially. Instead, events associated with a batch can start andstop at different times during the batch. Each grouping of events can beassociated with a particular sensor. The duration of events may bedifferent and when multiple events are happening at the same time thestart and stop time of the events may or may not be aligned. An exampleof this is as illustrated by “Event 1” 653 having a start time of 651(that is temporally aligned with the batch 105A start time 607A) and anend time of 651-1, thus event1 653 occurs for the time period A_(p1).“Event 3” 656 occurs during a portion of the time event1 653 occurs,“Event 3” having a start time of 656 and an end time of 651-1 and thusoccurring during the time period A_(p3). “Event 2” 654 occurs during thetime period A_(p2), and “Event 4” 657 occurs during the time periodA_(p4), which partially overlaps the occurrence of “Event 2” 654. “Eventn” 658 occurs during the time period A_(pn) and is the last eventassociated with batch 105A, and has an end time at 652 that correspondsto the end time 608A of batch 105A. As mentioned above, while notillustrated, separate groupings of events for a particular batch canhave the same start and/or end times.

In some examples, the events relate to a portion of a system that ismonitoring a batch during a particular time. In one example, where thebatch is a vehicle moving to a particular route, an event may be aparticular part of the route, as defined by specific geographic area, orby a split specific time. Also, if the batch is a vehicle, an event mayrelate to a certain portion of the vehicle thus defining one or moresensors that may be located in the certain portion of the vehicle tocapture time series data relating to the event. For example, the eventmay be a braking operation of the vehicle and sensors monitorcharacteristics of the braking operation for example heat, pressure,rotational speed, movement of braking mechanisms, noise, etc. also ifthe event is a braking operation of a vehicle, the event may take placein more than one location of the vehicle. In other words during thebraking operation event sensor data may be collected from multiplelocations on the vehicle, for example, at each wheel and at controlcomponents for the braking operation. Similarly, if the batch is a cakeand during the baking process the cake is baked in a first oven for aparticular time and a second oven for particular time, two events forthis batch may be the places the cake is located during baking, that is,the first oven and the second oven.

FIG. 6B also illustrates an example of data objects 601 that relate totime series information 600. The data objects 601 may be defined by anontology 205 to store information related to a batch, including timeseries data generated by one or more sensors that monitor the batch, asdescribed in reference to FIGS. 2-5. Data objects may store informationfor the batches 105, sensor data 110, determined data 115, quality data120, and events 625. In various examples, such data objects may bedefined in various ways, and FIG. 6 illustrates one example of such dataobjects 601. In some embodiments, a user interface for the data modelcan enable a user to configure the data objects 601, such as by definingbatch types, sensor types, other object information, and/orrelationships between the data objects, such as links between the dataobjects.

In this example, data objects 601 includes for each batch a data objectbatch 105A, which includes information relating to a particular batch.In this example data object batch 105S includes a batch identifier, thestart time, and end time, and one or more event identifiers indicatingparticular events that are associated with batch 105A. That is, theevent identifiers are the events that a batch experiences while is beingmonitored. Data objects 601 also includes a data object for each sensorrelated to a batch. In this example, such data objects include dataobject sensor 1 611A, data object sensor 2 612A, and data object sensorn 613A. Each of the sensor data objects 611A, 612A, 613A includesinformation relating to the sensor. In this example, each of sensor dataobjects 611A, 612A, 613A includes sensed data (data samples) and atimestamp indicating when the sensed data was captured. That is, eachdata sample has a corresponding timestamp, such as a timestamp for eachdata value.

Data objects 601 also includes a data object determined data 115A whichincludes a batch identifier, an event identifier, the determined datametric or information, and the timestamp indicating the time associatedwith the determined data. Data objects 601 also includes a data objectquality data 120A, which includes a batch identifier, an eventidentifier, quality indicator, and a timestamp. Data objects 601 furtherincludes data object events 653A, 654A, in 658A. Each of the data objectevents 653A, 654A, in 658A, includes an event identifier a start timeand an end time. In some embodiments, the data objects 601 do notinclude the data object quality data 120A.

By defining data objects to have certain links and properties isdescribed in reference to FIG. 2, and adding information to these dataobjects and defining links and properties of these data objects asdescribed in FIGS. 3, 4, and 5, the time series information 600associated with multiple batches that are each monitored by multiplesensors during multiple events can be organized and stored for lateruse. A user interface, such as a time series user interface, can thenuse these data objects to quickly and efficiently access specificportions of the time series data and plot the data for display on a userinterface. For example, the data objects 601 can be used to determinefrom time series data of a first sensor, a first subset of time seriesdata for a first batch from a desired first start time to a first endtime. The data objects 601 can also be used to determine, from timeseries data of the first sensor, a second subset of time series data forthe second batch from a second start time to a second end time. Thisdetermined data can then be used to generate a time series userinterface comprising a chart, the chart comprising a first plot for thefirst subset of time series data and a second plot for the second subsetof time series data, wherein the first plot is aligned to the secondplot such that the data can be compared, and the generated userinterface can be displayed and/or the time-aligned data provided to ananalysis system for identifying and/or alerting users through the userinterface of a particular condition, such as a fault.

Using data objects 601 that are stored on a computer storage medium,many different time series user interfaces may be generated, each of thetime series user interfaces comprising a different chart illustratingplots of different portions of the time series data. For example,portions of time series data relating to one or more of various sensors,various batches, various events, various determined information, and/orvarious quality data.

FIG. 7 is a block diagram that illustrates a computer system 700 uponwhich various embodiments may be implemented. Computer system 700includes a bus 702 or other communication mechanism for communicatinginformation, and a hardware processor, or multiple processors, 704coupled with bus 702 for processing information. Hardware processor(s)704 may be, for example, one or more general purpose microprocessors.

Computer system 700 also includes a main memory 706, such as a randomaccess memory (RAM), cache and/or other dynamic storage devices, coupledto bus 702 for storing information and instructions to be executed byprocessor 704. Main memory 706 also may be used for storing temporaryvariables or other intermediate information during execution ofinstructions to be executed by processor 704. Such instructions, whenstored in storage media accessible to processor 704, render computersystem 700 into a special-purpose machine that is customized to performthe operations specified in the instructions. The main memory 706 may,for example, include instructions to allow a user to manipulate timeseries data to store the time series data in data objects as defined byan ontology, as described in reference to FIGS. 2-5.

Computer system 700 further includes a read only memory (ROM) 708 orother static storage device coupled to bus 702 for storing staticinformation and instructions for processor 704. A storage device 710,such as a magnetic disk, optical disk, or USB thumb drive (Flash drive),etc., is provided and coupled to bus 702 for storing information andinstructions.

Computer system 700 may be coupled via bus 702 to a display 712, such asa cathode ray tube (CRT) or LCD display (or touch screen), fordisplaying information to a computer user. An input device 714,including alphanumeric and other keys, is coupled to bus 702 forcommunicating information and command selections to processor 704.Another type of user input device is cursor control 716, such as amouse, a trackball, or cursor direction keys for communicating directioninformation and command selections to processor 704 and for controllingcursor movement on display 712. This input device typically has twodegrees of freedom in two axes, a first axis (e.g., x) and a second axis(e.g., y), that allows the device to specify positions in a plane. Insome embodiments, the same direction information and command selectionsas cursor control may be implemented via receiving touches on a touchscreen without a cursor.

Computing system 700 may include a user interface module to implement aGUI that may be stored in a mass storage device as computer executableprogram instructions that are executed by the computing device(s).Computer system 700 may further, as described below, implement thetechniques described herein using customized hard-wired logic, one ormore ASICs or FPGAs, firmware and/or program logic which in combinationwith the computer system causes or programs computer system 700 to be aspecial-purpose machine. According to one embodiment, the techniquesherein are performed by computer system 700 in response to processor(s)704 executing one or more sequences of one or more computer readableprogram instructions contained in main memory 706. Such instructions maybe read into main memory 706 from another storage medium, such asstorage device 710. Execution of the sequences of instructions containedin main memory 706 causes processor(s) 704 to perform the process stepsdescribed herein. In alternative embodiments, hard-wired circuitry maybe used in place of or in combination with software instructions.

Various forms of computer readable storage media may be involved incarrying one or more sequences of one or more computer readable programinstructions to processor 704 for execution. For example, theinstructions may initially be carried on a magnetic disk or solid statedrive of a remote computer. The remote computer can load theinstructions into its dynamic memory and send the instructions over atelephone line using a modem. A modem local to computer system 700 canreceive the data on the telephone line and use an infra-red transmitterto convert the data to an infra-red signal. An infra-red detector canreceive the data carried in the infra-red signal and appropriatecircuitry can place the data on bus 702. Bus 702 carries the data tomain memory 706, from which processor 704 retrieves and executes theinstructions. The instructions received by main memory 706 mayoptionally be stored on storage device 710 either before or afterexecution by processor 704.

Computer system 700 also includes a communication interface 718 coupledto bus 702. Communication interface 718 provides a two-way datacommunication coupling to a network link 720 that is connected to alocal network 722. For example, communication interface 718 may be anintegrated services digital network (ISDN) card, cable modem, satellitemodem, or a modem to provide a data communication connection to acorresponding type of telephone line. As another example, communicationinterface 718 may be a local area network (LAN) card to provide a datacommunication connection to a compatible LAN (or WAN component tocommunicate with a WAN). Wireless links may also be implemented. In anysuch implementation, communication interface 718 sends and receiveselectrical, electromagnetic or optical signals that carry digital datastreams representing various types of information.

Network link 720 typically provides data communication through one ormore networks to other data devices. For example, network link 720 mayprovide a connection through local network 722 to a host computer 724 orto data equipment operated by an Internet Service Provider (ISP) 726.ISP 726 in turn provides data communication services through the worldwide packet data communication network now commonly referred to as the“Internet” 728. Local network 722 and Internet 728 both use electrical,electromagnetic or optical signals that carry digital data streams. Thesignals through the various networks and the signals on network link 720and through communication interface 718, which carry the digital data toand from computer system 700, are example forms of transmission media.

Computer system 700 can send messages and receive data, includingprogram code, through the network(s), network link 720 and communicationinterface 718. In the Internet example, a server 730 might transmit arequested code for an application program through Internet 728, ISP 726,local network 722 and communication interface 718. The received code maybe executed by processor 704 as it is received, and/or stored in storagedevice 710, or other non-volatile storage for later execution.

Accordingly, in some embodiments, of the computer system 700, thecomputer system comprises a first non-transitory computer storage mediumstorage device 710 configured to at least store for a plurality ofbatches, (i) first time series object data comprising a first start timeand a first end time for a first batch, and (ii) second time seriesobject data comprising a second start time and a second end time for asecond batch. The computer system 700 can further comprise a secondnon-transitory computer storage medium main memory 706 configured to atleast store computer-executable instructions. The computer system canfurther comprise one or more computer hardware processors 704 incommunication with the second non-transitory computer storage mediummain memory 706, the one or more computer hardware processors 704configured to execute the computer-executable instructions to at least:determine, from time series data from a first sensor, a first subset oftime series data for the first batch from the first start time and thefirst end time; determine, from the time series data from the firstsensor, a second subset of time series data for the second batch fromthe second start time and the second end time; generate a time seriesuser interface comprising a chart, the chart comprising a first plot forat least a portion of the first subset of time series data and a secondplot for at least a portion of the second subset of time series data,wherein the first plot is temporally aligned to the second plot; andcause presentation of the time series user interface on the display 712.The plots may be temporally aligned, for example, such that they aregraphically aligned. Either the first plot or the second plot may beshown in the chart as shifted in time so that they may begin at a samerelative time in the chart. For example, the temporal alignment of thefirst plot to the second plot may align the portion of the first subsetof time series data with the portion of the second subset of time seriesdata in the chart in a vertical or horizontal corresponding directionsuch that points of the first plot and the second plot along thecorresponding direction represent the same point in time relative to thestart of the respective first batch and second batch.

The computer system 700 can include many other aspects. In anembodiment, the one or more computer hardware processors 704 of thecomputer system 700 are further configured to execute thecomputer-executable instructions to receive and store user input plotdisplay range data for at least one of the first plot and the secondplot, and in response to receiving the user data, from user input device714, generate a time series user interface including a chart using theuser input plot display range data, the chart including a first plot forthe first subset of time series data and a second plot for the secondsubset of time series data, wherein the first plot is aligned to thesecond plot, wherein the user input display range data indicates aperiod of time. In another example, the one or more computer hardwareprocessors 704 of the computer system 700 are further configured toexecute the computer-executable instructions to determine, from timeseries data from a plurality of sensors, a corresponding number of oneor more additional subsets of time series data for the first batch fromthe first start time and the first end time of the first batch,determine, from the time series data from the plurality of sensors, acorresponding number of one or more additional subsets of time seriesdata for the second batch from the second start time and the second endtime of the second batch, and cause presentation of the time series userinterface. The chart may further include one or more additional plotscorresponding to the one or more additional subsets of time series data,wherein the one or more additional plots are also aligned and comparableto the first plot and the second plot. As described in reference toFIGS. 2-5, the one or more computer hardware processors 704 may beconfigured to execute the computer-executable instructions to generate auser interface for defining an object model to store the first timeseries object data and the second time series object data.

Various embodiments of the present disclosure may be a system, a method,and/or a computer program product at any possible technical detail levelof integration. The computer program product may include a computerreadable storage medium (or mediums) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent disclosure. For example, the functionality described herein maybe performed as software instructions are executed by, and/or inresponse to software instructions being executed by, one or morehardware processors and/or any other suitable computing devices. Thesoftware instructions and/or other executable code may be read from acomputer readable storage medium (or mediums).

The computer readable storage medium can be a tangible device that canretain and store data and/or instructions for use by an instructionexecution device. The computer readable storage medium may be, forexample, but is not limited to, an electronic storage device (includingany volatile and/or non-volatile electronic storage devices), a magneticstorage device, an optical storage device, an electromagnetic storagedevice, a semiconductor storage device, or any suitable combination ofthe foregoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a solid state drive, a random accessmemory (RAM), a read-only memory (ROM), an erasable programmableread-only memory (EPROM or Flash memory), a static random access memory(SRAM), a portable compact disc read-only memory (CD-ROM), a digitalversatile disk (DVD), a memory stick, a floppy disk, a mechanicallyencoded device such as punch-cards or raised structures in a groovehaving instructions recorded thereon, and any suitable combination ofthe foregoing. A computer readable storage medium, as used herein, isnot to be construed as being transitory signals per se, such as radiowaves or other freely propagating electromagnetic waves, electromagneticwaves propagating through a waveguide or other transmission media (e.g.,light pulses passing through a fiber-optic cable), or electrical signalstransmitted through a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions (as also referred to herein as,for example, “code,” “instructions,” “module,” “application,” “softwareapplication,” and/or the like) for carrying out operations of thepresent disclosure may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, configuration data for integrated circuitry, oreither source code or object code written in any combination of one ormore programming languages, including an object oriented programminglanguage such as Java, C++, or the like, and procedural programminglanguages, such as the “C” programming language or similar programminglanguages. Computer readable program instructions may be callable fromother instructions or from itself, and/or may be invoked in response todetected events or interrupts. Computer readable program instructionsconfigured for execution on computing devices may be provided on acomputer readable storage medium, and/or as a digital download (and maybe originally stored in a compressed or installable format that requiresinstallation, decompression or decryption prior to execution) that maythen be stored on a computer readable storage medium. Such computerreadable program instructions may be stored, partially or fully, on amemory device (e.g., a computer readable storage medium) of theexecuting computing device, for execution by the computing device. Thecomputer readable program instructions may execute entirely on a user'scomputer (e.g., the executing computing device), partly on the user'scomputer, as a stand-alone software package, partly on the user'scomputer and partly on a remote computer or entirely on the remotecomputer or server. In the latter scenario, the remote computer may beconnected to the user's computer through any type of network, includinga local area network (LAN) or a wide area network (WAN), or theconnection may be made to an external computer (for example, through theInternet using an Internet Service Provider). In some embodiments,electronic circuitry including, for example, programmable logiccircuitry, field-programmable gate arrays (FPGA), or programmable logicarrays (PLA) may execute the computer readable program instructions byutilizing state information of the computer readable programinstructions to personalize the electronic circuitry, in order toperform aspects of the present disclosure.

Aspects of the present disclosure are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of thedisclosure. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart(s) and/or block diagram(s)block or blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks. For example, the instructions may initially be carried on amagnetic disk or solid state drive of a remote computer. The remotecomputer may load the instructions and/or modules into its dynamicmemory and send the instructions over a telephone, cable, or opticalline using a modem. A modem local to a server computing system mayreceive the data on the telephone/cable/optical line and use a converterdevice including the appropriate circuitry to place the data on a bus.The bus may carry the data to a memory, from which a processor mayretrieve and execute the instructions. The instructions received by thememory may optionally be stored on a storage device (e.g., a solid statedrive) either before or after execution by the computer processor.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present disclosure. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the blocks may occur out of theorder noted in the Figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. In addition, certain blocks may be omitted insome implementations. The methods and processes described herein arealso not limited to any particular sequence, and the blocks or statesrelating thereto can be performed in other sequences that areappropriate.

It will also be noted that each block of the block diagrams and/orflowchart illustration, and combinations of blocks in the block diagramsand/or flowchart illustration, can be implemented by special purposehardware-based systems that perform the specified functions or acts orcarry out combinations of special purpose hardware and computerinstructions. For example, any of the processes, methods, algorithms,elements, blocks, applications, or other functionality (or portions offunctionality) described in the preceding sections may be embodied in,and/or fully or partially automated via, electronic hardware suchapplication-specific processors (e.g., application-specific integratedcircuits (ASICs)), programmable processors (e.g., field programmablegate arrays (FPGAs)), application-specific circuitry, and/or the like(any of which may also combine custom hard-wired logic, logic circuits,ASICs, FPGAs, etc. with custom programming/execution of softwareinstructions to accomplish the techniques).

Any of the above-mentioned processors, and/or devices incorporating anyof the above-mentioned processors, may be referred to herein as, forexample, “computers,” “computer devices,” “computing devices,” “hardwarecomputing devices,” “hardware processors,” “processing units,” and/orthe like. Computing devices of the above-embodiments may generally (butnot necessarily) be controlled and/or coordinated by operating systemsoftware, such as Mac OS, iOS, Android, Chrome OS, Windows OS (e.g.,Windows XP, Windows Vista, Windows 7, Windows 8, Windows 10, WindowsServer, etc.), Windows CE, Unix, Linux, SunOS, Solaris, Blackberry OS,VxWorks, or other suitable operating systems. In other embodiments, thecomputing devices may be controlled by a proprietary operating system.Conventional operating systems control and schedule computer processesfor execution, perform memory management, provide file system,networking, I/O services, and provide a user interface functionality,such as a graphical user interface (“GUI”), among other things.

FIG. 8A illustrates two examples of displayed user interfaces that candisplay time series data associated with batches, the time series dataorganized and stored using an ontology as described herein. In oneexample, user interface 810 includes chart 812, which includes two plots813, 814 of time series data. Plot 813 is a graphical representation oftime series data of batch 1, collected by sensor 1 over a time periodstarting at time t1 and ending at time t4. Plot 814 is a graphicalrepresentation of time series data of batch 2, collected by sensor 1over a time period starting at time t41 and ending at time t44. In thisexample, batch 1 and batch 2 were run on, and/or were monitored by, thesame system such that sensor 1 collected time series data for both batch1 and batch 2, but at different times (in this case, the sensor 1 datain plot 814 was collected subsequent to the sensor 1 data in plot 813).In this example, batch 1 had a start time at t1 and an end time at t30.Thus, the time period of plot 813 defined by t1 to t4 represents asubset of the duration of the total time of batch 1. Also in thisexample, batch 2 had a start time at t41 and an end time at t70 time.Thus, the time period of plot 814 defined by t40 to t44 represents asubset of the duration of the total time of batch 2.

Plot 813 and plot 814 are displayed in user interface 810 such thatcorresponding time instances in batch 1 and batch 2 are aligned for easycomparison. In other words, the time series data represented by plot 813and plot 814 has been temporally adjusted such that instances in thetimeline of each batch correspond in a vertical direction relative tothe page. A corresponding data point on plot 813 and plot 814, asillustrated by the arrows of line 815, was collected by sensor 1 at thesame relative time At in the batch 1 and batch 2 processing, that is,when compared to the start time of the batch. Similarly, the arrows ofline 816 also indicate corresponding data points on plot 813 and 814. Inthis way time series sensor data generated by the same sensor indifferent batches may be displayed simultaneously such that the data istemporally aligned and comparable for ease of analysis of the timeseries sensor data.

While this example shows chart 810 as illustrating time series sensordata of plots of a single sensor for two different batches, the userinterface can also be generated to show any portion (or subset) ofcollected time series data (for example time series data that includessensor data, determine data, and/or quality data). Also, in variousother examples, a user interface can be generated to have various typesof plots that can include various combinations of the collected timeseries data, for example, any combination of time series data related toone or more different batches, one or more different sensors, fordifferent processes and over different timeframes. In some examples, forease of analysis, any time series data stored in the database for two ormore batches can be displayed on the same plot. In some examples, a usercan input an indication of a time range or period of time series datathat they want to have displayed as the time scale in the one or moreplots. In one example, to indicate the time for which the data is to bedisplayed, a user can enter a start time and an end time. In anotherexample, the user can enter a start time and then a length of time afterthe starting time. In another example, a user can indicate an eventassociated with the batch and the time series data collected during theevent or a portion of the event can be displayed.

FIG. 8A shows another example of a user interface 820 that can begenerated that illustrates a chart 822 that includes a first plot forbatch 3 showing time series sensor data 823 for sensor 3 and time seriessensor data 824 for sensor 4. The plot for batch 3 represents a subsetof the time series data collected for batch 3 and is shown here fromtime t12 to time t20. User interface 820 also illustrates in chart 822 asecond plot for batch 4 showing time series sensor data 825 for sensor 3and time series sensor data 826 for sensor 4. The plot for batch 4represents a subset of the time series data collected for batch 3 and isshown here from time t12 to time t20. In this example, the time seriesdata collected for batch 3 and batch 4 were collected on two differentsystems, for at least a portion of the same time. Also in this examplethe user interface 820 was also generated to have a time range for batch3 from t12 to t20, and a different time range t12 to t20 for batch 4.Such a user interface can be used to compare aligned time series datafrom multiple sensors for batches associated with two different systems.

FIG. 8B shows another example of the user interface 810, similar to thatshown in FIG. 8A, in which the analysis system identifies a variationbetween plots 813 and 814, at a time indicated by reference numeral 817,that meets a predetermined alert condition, e.g. because the variationbetween the plot values at a corresponding time is greater than acertain predetermined threshold. In response to this, a prompt 819 maybe displayed alerting the user via the user interface 810 and enablingthe user to turn-off the sensor, or in some cases, the underlyingsystem, for example, during a subsequent operation of the system.

In various embodiments certain functionality may be accessible by a userthrough a web-based viewer (such as a web browser), or other suitablesoftware program). In such implementations, the user interface may begenerated by a server computing system and transmitted to a web browserof the user (e.g., running on the user's computing system).Alternatively, data (e.g., user interface data) necessary for generatingthe user interface may be provided by the server computing system to thebrowser, where the user interface may be generated (e.g., the userinterface data may be executed by a browser accessing a web service andmay be configured to render the user interfaces based on the userinterface data). The user may then interact with the user interfacethrough the web-browser. User interfaces of certain implementations maybe accessible through one or more dedicated software applications. Incertain embodiments, one or more of the computing devices and/or systemsof the disclosure may include mobile computing devices, and userinterfaces may be accessible through such mobile computing devices (forexample, smartphones and/or tablets).

FIG. 9 is an example of a flowchart of a method 900 presenting timeseries data in a user interface. In an embodiment, method 900 can beperformed using the computer system 700 described in reference to FIG.7. At block 905, the method 900 stores first time series object datacomprising a first start time and/or a first end time for a first batch.At block 910, the method 900 stores second time series object datacomprising a second start time and/or a second end time for a secondbatch. The first time series object data and the second time seriesobject may relate to any time series data that has been parsed andorganized as defined by an ontology, as described herein, for example,in FIGS. 2 through 5.

At block 915, using one or more computer hardware processors incommunication with a second non-transitory computer storage mediumconfigured to at least store computer-executable instructions, themethod 900 determines, from time series data from a first sensor, afirst subset of time series data for the first batch from the firststart time and the first end time. At block 920, using one or morecomputer hardware processors in communication with a secondnon-transitory computer storage medium configured to at least storecomputer-executable instructions, the method 900 determines, from thetime series data from the first sensor, a second subset of time seriesdata for the second batch from the second start time and the second endtime. The first subset of time series data in the second subset of sitetime series data may relate to an event that occurs in both batch 1 andbatch 2, for example as described in reference to FIG. 6A and 6B.

At block 925, the method 900 generates a time series user interfacecomprising a chart, the chart comprising a first plot for at least aportion of the first subset of time series data and a second plot for atleast a portion of the second subset of time series data, wherein thefirst plot is temporally aligned to the second plot. The temporalalignment of the first plot to the second plot aligns the portion of thefirst subset of time series data with the portion of the second subsetof time series data in the chart in a vertical or horizontalcorresponding direction such that points of the first plot and thesecond plot along the corresponding direction represent the same pointin time relative to the start of the respective first batch and secondbatch.

Temporal alignment of first and second time series data can includeusing a time shift operation. In some embodiments, the time series userinterface can query an application programming interface (API) toretrieve time series data from a data store; moreover, the API caninclude parameters to request data in a particular format. First timeseries data can be associated with a first batch and a first startand/or stop times. Second time series data can be associated with asecond batch and a second start and/or stop times. The first and secondtime series data can be associated with same sensor. However, asdescribed herein, the first and second start and stop times can bedifferent, but it may advantageous for a user view the time series datafor the first and second batches as temporally aligned for comparisonpurposes. Accordingly, a relative time axis can be shown in the userinterface.

Temporal aligning time series can include requesting the first andsecond time series data for a period of time, which can be performedpartially or entirely at blocks 905 and 910. In some embodiments, theperiod of time can be defined by the start and end time of a batch. Inother embodiments, the period of time can be selected by a user. Anexample period of time can include 1 minute, 1 hour, 1 day, or 30 days,for example. Thus, the first time series data can be retrieved for thefirst batch using the start time for the first batch and the period oftime; the second time series data can be retrieved for the second batchusing the start time for the second batch and the period of time. Boththe first and second time series data can be time shifted. In someembodiments, time shifting of the first and second time series data canbe performed by the API for requesting time series data. Time shiftingthe first and second time series data can include updating therespective timestamp data in each of the series data by setting a firsttimestamp in the time series data to “zero,” which allows presentationof the first and second time series on a relative time series axis.Setting a first timestamp to “zero” can include actually setting thetimestamp to a zero timestamp value or to a particular common timestampsuch as Jan. 1, 2017 12:00 AM or some other timestamp. The remainingtimestamps in the time series data can be adjusted relative to the firsttimestamp in the time series data being set to zero. Setting the initialtime series data values to zero for multiple sets of time series datacan advantageously allow the time series user interface to allowoperations such as combining two or more time series by addition,subtraction, multiplication, averaging, statistical operations,interpolation, or some other operation.

Finally, at block 930, method 900 causes presentation of the time seriesuser interface. For example, the time series user interface may bepresented on display 712 described in reference to FIG. 7. The firsttime series object data may include the time series data for the firstsensor and time series data for at least one other sensor for the firstbatch. The second time series object data includes the time series datafor the second sensor and time series data for at least one other sensorfor the second batch.

The method 900 may also include receiving and storing user input plotdisplay range data for at least one of the first plot and the secondplot, where generating the time series user interface comprises, inresponse to receiving the user data, generating using the one or morecomputer hardware processors the time series user interface comprisingthe chart using the stored user input plot display range data.

The method 900 may also include using the one or more computer hardwareprocessors, determining, from time series data from at least oneadditional sensor, at least a third subset of time series data for thefirst batch from the first start time and the first end time of thefirst batch, determining, from time series data from the at least oneadditional sensor, at least a fourth subset of time series data for thefirst batch from the first start time and the first end time of thefirst batch. The chart presented in the time series user interfaceincludes additional plots corresponding to the at least one additionalsensor, wherein the additional plots are also temporally aligned andtemporally aligned to the first plot and the second plot.

Many variations and modifications may be made to the above-describedembodiments, the elements of which are to be understood as being amongother acceptable examples. All such modifications and variations areintended to be included herein within the scope of this disclosure. Theforegoing description details certain embodiments. It will beappreciated, however, that no matter how detailed the foregoing appearsin text, the systems and methods can be practiced in many ways. As isalso stated above, it should be noted that the use of particularterminology when describing certain features or aspects of the systemsand methods should not be taken to imply that the terminology is beingre-defined herein to be restricted to including any specificcharacteristics of the features or aspects of the systems and methodswith which that terminology is associated.

Conditional language, such as, among others, “can,” “could,” “might,” or“may,” unless specifically stated otherwise, or otherwise understoodwithin the context as used, is generally intended to convey that certainembodiments include, while other embodiments do not include, certainfeatures, elements, and/or steps. Thus, such conditional language is notgenerally intended to imply that features, elements and/or steps are inany way required for one or more embodiments or that one or moreembodiments necessarily include logic for deciding, with or without userinput or prompting, whether these features, elements and/or steps areincluded or are to be performed in any particular embodiment.

The term “substantially” when used in conjunction with the term“real-time” forms a phrase that will be readily understood by a personof ordinary skill in the art. For example, it is readily understood thatsuch language will include speeds in which no or little delay or waitingis discernible, or where such delay is sufficiently short so as not tobe disruptive, irritating, or otherwise vexing to a user.

Conjunctive language such as the phrase “at least one of X, Y, and Z,”or “at least one of X, Y, or Z,” unless specifically stated otherwise,is to be understood with the context as used in general to convey thatan item, term, etc. may be either X, Y, or Z, or a combination thereof.For example, the term “or” is used in its inclusive sense (and not inits exclusive sense) so that when used, for example, to connect a listof elements, the term “or” means one, some, or all of the elements inthe list. Thus, such conjunctive language is not generally intended toimply that certain embodiments require at least one of X, at least oneof Y, and at least one of Z to each be present.

The term “a” as used herein should be given an inclusive rather thanexclusive interpretation. For example, unless specifically noted, theterm “a” should not be understood to mean “exactly one” or “one and onlyone”; instead, the term “a” means “one or more” or “at least one,”whether used in the claims or elsewhere in the specification andregardless of uses of quantifiers such as “at least one,” “one or more,”or “a plurality” elsewhere in the claims or specification.

The term “comprising” as used herein should be given an inclusive ratherthan exclusive interpretation. For example, a general purpose computercomprising one or more processors should not be interpreted as excludingother computer components, and may possibly include such components asmemory, input/output devices, and/or network interfaces, among others.

While the above detailed description has shown, described, and pointedout novel features as applied to various embodiments, it may beunderstood that various omissions, substitutions, and changes in theform and details of the devices or processes illustrated may be madewithout departing from the spirit of the disclosure. As may berecognized, certain embodiments of the inventions described herein maybe embodied within a form that does not provide all of the features andbenefits set forth herein, as some features may be used or practicedseparately from others. The scope of certain inventions disclosed hereinis indicated by the appended claims rather than by the foregoingdescription. All changes which come within the meaning and range ofequivalency of the claims are to be embraced within their scope.

1. A system comprising: a first non-transitory computer storage mediumconfigured to at least store for a plurality of batches: (i) first timeseries object data comprising a first start time and a first end timefor a first batch, and (ii) second time series object data comprising asecond start time and a second end time for a second batch; a secondnon-transitory computer storage medium configured to at least storecomputer-executable instructions; and one or more computer hardwareprocessors in communication with the second non-transitory computerstorage medium, the one or more computer hardware processors configuredto execute the computer-executable instructions to at least: determine,from time series data from a first sensor, a first subset of time seriesdata for the first batch from the first start time and the first endtime; determine, from the time series data from the first sensor, asecond subset of time series data for the second batch from the secondstart time and the second end time; generate a time series userinterface comprising a chart, the chart comprising a first plot for atleast a portion of the first subset of time series data and a secondplot for at least a portion of the second subset of time series data,wherein the first plot is temporally aligned to the second plot; andcause presentation of the time series user interface.
 2. The system ofclaim 1, wherein the first time series object data includes the timeseries data for the first sensor, and the second time series object dataincludes the time series data for the second sensor.
 3. The system ofclaim 1, wherein the first time series object data includes the timeseries data for the first sensor and time series data for at least oneother sensor for the first batch, and the second time series object dataincludes the time series data for the second sensor and time series datafor at least one other sensor for the second batch.
 4. The system ofclaim 1, wherein the one or more computer hardware processors arefurther configured to execute the computer-executable instructions toreceive and store user input plot display range data for at least one ofthe first plot and the second plot, and in response to receiving theuser input plot range data generate a time series user interfacecomprising a chart using the stored user input plot display range data,the chart comprising a first plot for the first subset of time seriesdata and a second plot for the second subset of time series data,wherein the first plot is aligned to the second plot, wherein the userinput display range data indicates a period of time.
 5. The system ofclaim 1, wherein the first start time and first end time representinstances in time, the first end time being after the first start time,the second start time and second end time represent instances in time,the second end time being after the second start time, and the firststart time and the second start time are different instances in time,and the first end time of the second end time are different instances intime.
 6. The system of claim 5, the one or more computer hardwareprocessors further configured to execute the computer-executableinstructions to generate the time series user interface such that thefirst start time of the first subset of time series data in the firstplot and the second start time of the second subset of time series datain the second plot are graphically aligned in the chart.
 7. The systemof claim 5, the one or more computer hardware processors furtherconfigured to execute the computer-executable instructions to generatethe time series user interface such that first plot and the second plotare aligned, having the first subset of time series data in the firstplot and the second subset of time series data in the second plot shownin the chart as beginning at a same relative time.
 8. The system ofclaim 4, wherein the one or more computer hardware processors arefurther configured to execute the computer-executable instructions toreceive and store user input plot display range data for at least one ofthe first plot and the second plot, and in response to receiving theuser data generate a time series user interface comprising a chart usingthe stored user input plot display range data, the chart comprising afirst plot of the first portion of the first subset of time series dataand a second plot of the second portion of the second subset of thesecond time series data, wherein the first plot is aligned to the secondplot.
 9. The system of claim 1, wherein the one or more computerhardware processors are further configured to execute thecomputer-executable instructions to: determine, from time series datafrom a second sensor, a third subset of time series data for the firstbatch from the first start time and the first end time of the firstbatch; determine, from the time series data from the second sensor, afourth subset of time series data for the second batch from the secondstart time and the second end time of the second batch; and causepresentation of the time series user interface, wherein the chartfurther comprises a first plot for the third subset of time series dataand a second plot for the fourth subset of time series data, wherein thefirst plot is aligned and comparable to the second plot.
 10. The systemof claim 3, wherein the one or more computer hardware processors arefurther configured to execute the computer-executable instructions to:determine, from time series data from one or more additional sensors, acorresponding number of one or more additional subsets of time seriesdata for the first batch from the first start time and the first endtime of the first batch; determine, from the time series data from theone or more additional sensors, a corresponding number of one or moreadditional subsets of time series data for the second batch from thesecond start time and the second end time of the second batch; and causepresentation of the time series user interface, wherein the chartfurther comprises one or more additional plots corresponding to the oneor more additional subsets of time series data, wherein the one or moreadditional plots are also aligned and comparable to the first plot andthe second plot.
 11. The system of claim 1, wherein the one or morecomputer hardware processors are configured to execute thecomputer-executable instructions to generate a user interface fordefining an object model to store the first time series object data andthe second time series object data.
 12. A method of presenting timeseries data in a user interface, the method comprising: storing firsttime series object data comprising a first start time and a first endtime for a first batch; storing second time series object datacomprising a second start time and a second end time for a second batch;using one or more computer hardware processors in communication with asecond non-transitory computer storage medium configured to at leaststore computer-executable instructions, determining, from time seriesdata from a first sensor, a first subset of time series data for thefirst batch from the first start time and the first end time;determining, from the time series data from the first sensor, a secondsubset of time series data for the second batch from the second starttime and the second end time; generating a time series user interfacecomprising a chart, the chart comprising a first plot for at least aportion of the first subset of time series data and a second plot for atleast a portion of the second subset of time series data, wherein thefirst plot is temporally aligned to the second plot; and causingpresentation of the time series user interface.
 13. The method of claim12, wherein the temporal alignment of the first plot to the second plotaligns the portion of the first subset of time series data with theportion of the second subset of time series data in the chart in avertical or horizontal corresponding direction such that points of thefirst plot and the second plot along the corresponding directionrepresent the same point in time relative to the start of the respectivefirst batch and second batch.
 14. The method of claim 12, wherein thefirst time series object data includes the time series data for thefirst sensor and time series data for at least one other sensor for thefirst batch, and the second time series object data includes the timeseries data for the second sensor and time series data for at least oneother sensor for the second batch.
 15. The method of claim 12, furthercomprising: receiving and storing user input plot display range data forat least one of the first plot and the second plot, and whereingenerating the time series user interface comprises, in response toreceiving the user data, generating using the one or more computerhardware processors the time series user interface comprising the chartusing the stored user input plot display range data.
 16. The method ofclaim 12, further comprising: using the one or more computer hardwareprocessors, determining, from time series data from at least oneadditional sensor, at least a third subset of time series data for thefirst batch from the first start time and the first end time of thefirst batch; determining, from time series data from the at least oneadditional sensor, at least a fourth subset of time series data for thefirst batch from the first start time and the first end time of thefirst batch; and causing presentation of the time series user interface,wherein the chart further comprises additional plots corresponding tothe at least one additional sensor, wherein the additional plots arealso temporally aligned and temporally aligned to the first plot and thesecond plot.
 17. The method of claim 12, wherein the first time seriesobject data includes the time series data for the first sensor, and thesecond time series object data includes the time series data for thesecond sensor.
 18. The method of claim 12, further comprising receivingand storing user input plot display range data for at least one of thefirst plot and the second plot, and in response to receiving the userinput plot range data generating a time series user interface comprisinga chart using the stored user input plot display range data, the charthaving a first plot for the first subset of time series data and asecond plot for the second subset of time series data, wherein the firstplot is aligned to the second plot, wherein the user input display rangedata indicates a period of time.
 19. The method of claim 12, wherein thefirst start time and first end time represent instances in time, thefirst end time being after the first start time, the second start timeand second end time represent instances in time, the second end timebeing after the second start time, and the first start time and thesecond start time are different instances in time, and the first endtime of the second end time are different instances in time.
 20. Themethod of claim 19, further comprising generating the time series userinterface such that the first start time of the first subset of timeseries data in the first plot and the second start time of the secondsubset of time series data in the second plot are graphically aligned inthe chart.